Hi Dan,
It is a bit incorrect to say that the Java Pet Store Demo is not
thread-safe. What you really want to say is that in the case of
concurrent browser requests, the second request will receive an
exception.
As for fixing that problem, as you also have mentioned, we need to
serialize calls to session ejbs at the web-tier itself.
thanks
inder
dan benanav wrote:
>
> I have concluded that the Pet Store demo is not thread-safe and that there is no
>currently recommended way to us a
> session bean for storing session state for a web-based client.
>
> Can we get a definitive answer from Sun on this?
>
> 1) Do you agree the Pet Store Demo is not thread safe? If not where is the flaw in
>my argument?
> 2) What should be done to store session state? (See below for suggestions)
>
> We might have hundreds of programmers following the recommendations and writing
>unsafe code.
>
> dan
>
> dan benanav wrote:
>
> > No it doesn't help. The original question concerns how to use a session bean from
>a servlet. I think that the
> > obvious way to use it leads to unsafe code. That is, the servlet saves a
>reference to the session bean in an
> > HttpSession object. That is what was done in the Pet Store Demo and what is
>suggested in the Sun BluePrint
> > (Formerly Application Programming Model). Since we seem to be saying clients are
>not allowed to make
> > concurrent calls to a session object one should not do that.
> >
> > So the real question is what is the proper way to use a session bean from a
>servlet?
> >
> > Possible answers seem to be:
> >
> > 1. Wrap the method calls to a session bean in another web object that
>synchronized the calls.
> > 2. Implement a locking mechanism in the servlet an obtain a lock before using the
>session bean and release
> > when done.
> >
> > I don't really like either of these approaches since the programming is now having
>to do "system level"
> > programming, something that is supposed to be unnecessary by using ejb.
> >
> > A possible 3rd approach is to:
> >
> > 3. Use an entity bean to keep track of the session information.
> >
> > For 3 the programmer would have to take care of the life cycle of the bean. In
>particular when the session
> > expires the bean should be destroyed.
> >
> > Maybe 3 is the best approach?
> >
> > I must say also that I am quite surprised about the number of people who
>incorrectly believe that session
> > object methods can be called concurrently and that there appears to be no standard
>way to use a session object
> > from a servlet to keep track of session specific information. It concerns me that
>after all this time it is
> > still not clear.
> >
> > Mark Cade wrote:
> >
> > > Dan,
> > >
> > > I agree with the sentence that clients are not allowed to make concurrent
>calls to a session object,
> > > but the specification cannot control the client so the specification put in the
>provision to throw a
> > > remote exception when the client attempts to make concurrent calls. If you
>choose to control this in
> > > your client, that is fine or you can let the bean take care of this for you and
>catch the remote exception.
> > >
> > > Hope this helped.
> > >
> > > Mark
> > > >Assad,
> > > >
> > > >Your are completely ignoring the sentence:
> > > >
> > > >Clients are not allowed to make concurrent calls to a session object.
> > > >
> > > >Note that it says, clients, not the container. What is your interpretation of
> > > >that
> > > >sentence? I believe you are misinterpreting the section on serialization. The
> > > >container
> > > >will make calls to the bean and must serialize those calls. For example it
> > > >should not
> > > >call ejbPassivate while invoking a method on the bean.
> > > >
> > > >dan
> > > >
> > > >Assaf Arkin wrote:
> > > >
> > > >> Please accept my apology for not responding directly to the argument you
> > > >> made. I was just too busy conversing with RMH on the CMP implementation.
> > > >>
> > > >> Section 6.5 defines the contract between the container and the bean. The
> > > >> container will assure that all access to a bean instance are serialized.
> > > >> Period. A bean does not have to be re-entrant.
> > > >>
> > > >> However, (please refer to pages 67/68) when invoking a method on a
> > > >> stateless session bean the container can choose a different instance for
> > > >> each method invocation. That means that concurrent method invocation can
> > > >> occur by delegating them to two separate instances.
> > > >>
> > > >> So, if you have one remote interface into a stateless session bean and
> > > >> perform concurrent method invocation, you get to instances two serve the
> > > >> two method calls. Pretty much the same as using two different remote
> > > >> interfaces, since the interface is not tied to any particular instance.
> > > >>
> > > >> There is just no other way to deal with stateless session beans in a
> > > >> distributed environment.
> > > >>
> > > >> arkin
> > > >>
> > > >> dan benanav wrote:
> > > >> >
> > > >> > Assaf Arkin wrote:
> > > >> >
> > > >> > > That's exactly what I was reading. The "container serializes" means that
> > > >> > > the container is responsible for serialization, not the application. You
> > > >> > > can write an application that perform concurrent calls to the same bean
> > > >> > > without needing to synchronize the access. The container will make that
> > > >> > > happen for you.
> > > >> >
> > > >> > You missed the sentence that says:
> > > >> >
> > > >> > Clients are not allowed to make concurrent calls to a session object.
> > > >> > > If a client-invoked business method
> > > >> > > is in progress on an instance when another client-invoked call, from
> > > >> > > the same or different client, arrives
> > > >> > > at the same instance, the container must throw the
> > > >> > > java.rmi.RemoteException to the second cli-ent.
> > > >> >
> > > >> > That seems pretty clear to me.
> > > >> >
> > > >> > The sentence you refer to is saying something else. The container
> > > >serializes calls
> > > >> > that it makes to the bean. For example it should not call ejbPassivate and a
> > > >method
> > > >> > of the bean simultaneously from two separate threads. For example the
> > > >container
> > > >> > needs to be careful not to call ejbPassivate while it is in the process of
> > > >invoking
> > > >> > a business method. Hence it needs to serialize these calls.
> > > >> >
> > > >> > > Why is that important? If you are running two threads that access the
> > > >> > > same bean, you can use synchronized() on the bean object to perform
> > > >> > > serialized access. But if you passed your handle to an application on a
> > > >> > > different machine, both your application and the other one might attempt
> > > >> > > to access the bean at the same time. There is no distributed
> > > >> > > synchronized() mechanism, so the responsibility falls on the container.
> > > >> > >
> > > >> > > Loopback is indeed not supported in some beans, supported but highly
> > > >> > > discouraged in other beans (this is spelled out in the entity bean
> > > >> > > section). It doesn't prevent recursion if that recursion is performed
> > > >> > > inside the bean, but not across beans.
> > > >> > >
> > > >> > > arkin
> > > >> > >
> > > >> > > dan benanav wrote:
> > > >> > > >
> > > >> > > > > Assaf, notice the bold text below taken from the spec.
> > > >> > > >
> > > >> > > > 6.5.6 Serializing session bean methods
> > > >> > > > A container serializes calls to each session bean instance. Most
> > > >> > > > containers will support many instances
> > > >> > > > of a session bean executing concurrently; however, each instance sees
> > > >> > > > only a serialized sequence of
> > > >> > > > method calls. Therefore, a session bean does not have to be coded as
> > > >> > > > reentrant.
> > > >> > > > The container must serialize all the container-invoked callbacks (that
> > > >> > > > is, the methods ejbPassivate,
> > > >> > > > beforeCompletion, and so on), and it must serialize these callbacks
> > > >> > > > with the client-invoked busi-ness
> > > >> > > > method calls.
> > > >> > > >
> > > >> > > > One implication of this rule is that it is illegal to make a
> > > >> > > > ?loopback? call to a session bean instance.
> > > >> > > > An example of a loopback call is when a client calls instance A,
> > > >> > > > instance A calls instance B, and B calls
> > > >> > > > A. The loopback call attempt from B to A would result in the container
> > > >> > > > throwing the
> > > >> > > > java.rmi.RemoteException to B.
> > > >> > > > Assaf Arkin wrote:
> > > >> > > >
> > > >> > > > > Let the EJB server deal with synchronized access. That's what it was
> > > >> > > > >
> > > >> > > > > designed to do.
> > > >> > > > >
> > > >> > > > > arkin
> > > >> > > > >
> > > >> > > > > dan benanav wrote:
> > > >> > > > > >
> > > >> > > > > > I am confused about how to use EJB session beans from servlets.
> > > >> > > > > Isn't
> > > >> > > > > > is true that EJB session beans should only be accessed by one
> > > >> > > > > thread at
> > > >> > > > > > a time and that the client must enforce that? If that is the case
> > > >> > > > > then
> > > >> > > > > > doesn't that mean that an EJB session bean should not be saved in
> > > >> > > > > a
> > > >> > > > > > session object, since session objects can be accessed by more then
> > > >> > > > > one
> > > >> > > > > > thread at a time. (I am referring to session objects in the
> > > >> > > > > servlet
> > > >> > > > > > sense now, not the ejb sense.) This happens when multiple
> > > >> > > > > windows are
> > > >> > > > > > open or when frames are used.
> > > >> > > > > >
> > > >> > > > > > For example, it looks to me like the ejb session beans are saved
> > > >> > > > > in
> > > >> > > > > > various session object of the Pet Store demo. Doesn't this mean
> > > >> > > > > the
> > > >> > > > > > demo is not thread safe?
> > > >> > > > > >
> > > >> > > > > > dan
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >===========================================================================
> > > >> > > > >
> > > >> > > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in
> > > >> > > > > the body
> > > >> > > > > > of the message "signoff EJB-INTEREST". For general help, send
> > > >> > > > > email to
> > > >> > > > > > [EMAIL PROTECTED] and include in the body of the message
> > > >> > > > > "help".
> > > >> > >
> > > >> > > --
> > > >> > > ----------------------------------------------------------------------
> > > >> > > Assaf Arkin www.exoffice.com
> > > >> > > CTO, Exoffice Technologies, Inc. www.exolab.org
> > >
> > > ===========================================================================
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > > of the message "signoff EJB-INTEREST". For general help, send email to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> > ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
