If a Stateless Bean calls a method on himself...


EJB design: If a Stateless Bean calls a method on himself...

  1. Hi,

        I had (yet another) basic question about Stateless EJBs: from your previous responses it is clear that different method calls on the same Remote can potentially hit different bean instances.

    Question 1
    Now, what if from within a bean method I call another bean method. In this case I should be guaranteed to hit the same instance. Am I right?

    Question 2
    I heard that in one of the version of EJB specs, you are guaranteed that no two clients share the same bean instance. Is this true?

    Now if the answer is yes to both Q1 and Q2, then it should be possible to set an attribute at the bean class level and "share" it between method calls, as long as the multiple method calls come from the bean itself.

    Can anybody confirm this?


  2. You are correct on all points.

    You can guarantee that only one client will be accessing any given instance at any one time (the container deals with this). So you can set instance variables and use them between methods.

    Be careful however, as the instance variables will retain their values for the next unsuspecting client :-)

  3. 1) You are guaranteed you will get the same instance. This is not some special rule - when you access the methods in your bean you don't use the remote interface, and the container isn't involved at all. The method call is just a normal Java method call. If you used your own remote interface rather than made a local call, you would have gotten a different instance.

    2) If you mean no two clients will share the same bean instance concurrently - then yes, this is true. This is true for all types of beans in all versions of the psec (AFAIK).
    Note that entity beans can be re-entrant, but they will never serve two different clients (more formally, two different transactions) concurrently. They will only accept concurrent calls from the same transaction.

    I don't really understand your last statement... did the answers above clear it, or maybe you could rephrase?