You can use stateless session beans since the beans will store information
specific to a client.
James Cook wrote:
> Dan,
>
> The problem you are facing is not restricted to servlets, but rather the
> browser paradigm. I believe your argument is correct in those circumstances
> when the developer uses frames, and when the user opens multiple windows.
> Someone developing applications could experience similar "shortcomings" if
> they used threading in their application.
>
> The real crux of your problem deals with the server's ability to recognize
> an incoming clients session identification. How does the server magically
> determine that the client request belongs to ClientA and not ClientB? The
> spec does not specify *how* this will occur, so I imagine that there are a
> variety of techniques. You may find that they vary specifically based on the
> underlying platform, RMI versus CORBA.
>
> I hope that each vendor takes the time to weigh in on this issue. It is at
> this point that we have the opportunity to establish "best practices" for
> future development.
>
> jim
>
> PS: Have you actually tested your hypothesis? Do your servlets blow up with
> exceptions? If so, a workaround would be to store the state you were
> delegating to the stateful session bean in the servlet. Redesign your server
> interfaces to use stateless session beans.
>
> ----- Original Message -----
> From: dan benanav <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, January 18, 2000 6:19 AM
> Subject: Re: Thread Safety, Session beans,Saving in servlet sessions.
>
> > 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".
> >
>
> ===========================================================================
> 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".
