I think inder said it very well. Just one question as a follow-up.
What technique would you use to ensure that you synchronize properly when accessing
the bean? I successfully sync'ed on:
private static Object lock = new Object();
in my example. Is this the best approach? I don't think you can sync on the session
object or the bean reference, since it would actually be a different object in the
call stack.
It is probably necessary to sync on the entire session object, until you are sure that
a session reference is in the HTTP session object. This will prevent two servlet
threads from thinking the http session object does not have a reference yet, if it
hasn't been resolved yet.
I hope that more examples involving servlets and EJB point this very important (and
perhaps subtle) problem out.
jim
On Tue, 18 Jan 2000 18:32:57 -0800, Inderjeet Singh <[EMAIL PROTECTED]> wrote:
>Hi Dan,
>
>It is a bit incorrect to say that the Java Pet Store Demo is not
>thread-safe. What you really want to say is that in the case of
>concurrent browser requests, the second request will receive an
>exception.
>
>As for fixing that problem, as you also have mentioned, we need to
>serialize calls to session ejbs at the web-tier itself.
>
>thanks
>inder
>
>
>dan benanav wrote:
>>
>> 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".
