Hi,
What about saving the ior of the bean in a cookie or a hidden
field of the html file ? I belive this is the recommended way to
implement it with the app server I'm using.
Eyal.
----- Original Message -----
From: dan benanav <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: ��� ����� 18 ����� 2000 13:19
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".
