• Post Reply Bookmark Topic Watch Topic
  • New Topic

Session beans concurrency  RSS feed

 
Eric Cornely
Greenhorn
Posts: 9
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I'm trying to understand the concurrent model of each EJB session bean types.

The singleton is well documented and seems clear to me... Only one instance and many threads using it but each method by default is synchronized because @Lock is defaulted to WRITE. We can let multiple threads use on method with @Lock(READ).

The stateless beans are in a pool I think I read somewhere that the container will ensure only one thread is using one instance at a time but this instances are recycled/reused so many threads can use the same instance but one at a time.
  • Is this correct ? or is it possible that multi-threading occur in one instance of SLSB ?
  • If in the client I obtain a single reference of a SLSB and share this "instance reference" in multiple threads is it true that all the threads could use different instances on the server side ?


  • The stateful instance I obtain in the client is linked to one server instance and any method call will target the same instace. If many threads are using the same reference, all method calls will be synchronized and waiting for a certain amount of time that can be defined in @AccessTimeout and if the timeout is reach will end with a ConcurrentAccessException.
  • Can we use @Lock(READ) and let many thread use the same method like in a singleton ?


  • Many thanks for your help

     
    Ramy Nady
    Ranch Hand
    Posts: 115
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hello ,

    Is this correct ? or is it possible that multi-threading occur in one instance of SLSB ?

    For stateless and statefuel session bean you don't need to worry since container already handle this concurrency situation , the container ensure that ONLY one thread can access any bean instance at the same time.
    Container may serialize the requests to one bean instance or even using more than one instance but the he still ensure that ONLY one thread can access any bean instance at the same time.
    The same bean instance can handle more than one request but not simultaneously.

    If in the client I obtain a single reference of a SLSB and share this "instance reference" in multiple threads is it true that all the threads could use different instances on the server side ?

    I don't completely understand what exactly you mean by sharing instance in multiple threads , what ever situation you have container ensure that ONLY one thread can access any bean instance at the same time.

    Can we use @Lock(READ) and let many thread use the same method like in a singleton ?

    No the container never permits multi-threaded access to the actual stateful session bean instance. For this reason, Read/Write method locking metadata, as well as the bean-managed concurrency mode, are not applicable to stateful session beans and must not be used.

    Also the concurrency management type for bean-managed concurrency (BEAN) does not apply to stateful session beans.
     
    Eric Cornely
    Greenhorn
    Posts: 9
    Eclipse IDE Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks a lot for that clear explanation.

    Ramy Nady wrote:
    I don't completely understand what exactly you mean by sharing instance in multiple threads , what ever situation you have container ensure that ONLY one thread can access any bean instance at the same time.


    What I mean is I do a single JNDI lookup to obtain one reference of a SLSB in the client and pass that reference to many threads running concurrently. Then what does the server do ?
    Is it using different server instances concurrently or using any kind of lock as you confirmed it ensures one instance is not used by many thread at a time.

     
    Ramy Nady
    Ranch Hand
    Posts: 115
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It depends on the container -application server itself how to handle the concurrency , WebSphere can handle this situation different than Apache.

    We are sure as the Spec mention ONLY one thread can access any bean instance at the same time.
    and as I mentioned before Read/Write method locking metadata, as well as the bean-managed concurrency mode can't overwrite this feature.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!