Why not? You keep the state in the servlet and pass it to stateless session
beans on the server. Many applications (apps and servlets) work in this
manner. You pass state as parameters (or a properties file) to the stateless
session bean.
This approach also scales well, if you can minimize the amount of state sent
back and forth. It is not as useful as a substitute for a "shopping cart"
stateful session bean.
jim
----- Original Message -----
From: Dan Benanav <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 18, 2000 1:26 PM
Subject: Re: Thread Safety, Session beans,Saving in servlet sessions.
> 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".
>
===========================================================================
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".
