For Programmers: Free Programming Magazines  


Home > Archive > Java Beans > June 2004 > EJB and instance variables









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author EJB and instance variables
Venky

2004-06-17, 8:56 pm

Code snippetss

Jsp A

OrderBean myABean = getOrderBeanInstace(); // Do not look for syntax
please
myABean.ExecuteOrder("Pen");


Jsp B

OrderBean myBBean = getOrderBeanInstance();
myBBena.ExecuteOrder("Car");


class Bean
{
public String OrderItem;
public ExecuteOrder(String x)
{
OrderItem = x; // I am saving this as I have to share it with
other methods but is being simplfied here
sleep(3 mins)
SendORder(OrderItem); // as OrderItem may be changed in the
methods I intend to call in-lieu of sleep 3 mins
}
}


Now as you can see SendOrder is not guaranteed to send Pen for the
first Jsp and Car for th second Jsp. (EJB 2.1 FR specs Section 7.8)

I do not understand why. I looked in the net. When JSP 2 requires an
instance why the container (EJB) is not saving the context fully
(including OrderItem) of JSP A. If I push the OrderItem in the method
it will save the context and this will work. I am not lookign for
work-arounds but the reason for this specification.

JSP A or JSP B is not assured of sending the correct orderitem. It is
blamed upon the bean developer. The object's context (instead of
method's cotnext) if I am saying this right needs to be restored by
the container. Why this is not being specified ?

For an analogy if there are wine glasses available in the counter
(consdier them as beans). I come in fill it in with wine and take a
sip. I am swapped out. Then next person comes in and requests a glass.
He is given the same 'dirty' glass. Even that is okay with me. The
problem is when he is pre-empted I am getting a corrupted object.

This is all happening in a stateless environment with in a call. I am
not leaving VOLUNTARILY (so that it becomes a requirement for
statefulness between calls) but being pre-empted out by the
OS/JVM/Container (in a stateless environment). So my call is in
IN-FLIGHT.

Can someone explain the decision to leave the specs this way? I
believe Java Gurus have a reason to do this.

Thanks


Venky
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com