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".
