Meant to say you cannot use stateless session beans.
Dan Benanav wrote:
> 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".
===========================================================================
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".
