Because in either case whether the bean is stateless or stateful it cannot be accessed
concurrently according to the spec. However an HttpSession object can be called
concurrently in 2 cases.
1) User has multilple browser windows open.
2) Use of multiple frames.
If this happens then whether you are storing a stateless or stateful session bean a
remote
exception will be generated. (Again according to the spec the container has to throw a
remote exception).
Mark Cade wrote:
> Dan,
>
> I guess I'm confused. Are you referring to stateful or stateless session beans?
> If stateful, what is wrong with having a handle to the bean stored in the
>HttpSession?
> If stateless, then I agree with what you are saying.
>
> Mark
> >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".
