Accessing Stateful Session Bean from separate threads - urgent


EJB programming & troubleshooting: Accessing Stateful Session Bean from separate threads - urgent

  1. We have an application thatis considering the following scenario:

    A client acquires a reference to a Stateful Session bean. This client then starts a new thread passing it the reference to the remote interface. Once this process has completed the started thread will then use the EJB reference and update state information pertaining to that EJB.

    Is there an issue/limitation with multiple threads accessing the same stateful session bean?
  2. Hi

    The following text is from section 7.11.8 in EJB 2.0 spec:

    The container must ensure that only one thread can be executing an instance at any time. If a client
    request arrives for an instance while the instance is executing another request, the container may throw
    the java.rmi.RemoteException to the second request if the client is a remote client, or the
    javax.ejb.EJBException if the client is a local client. [6]

    Note that a session object is intended to support only a single client. Therefore, it would be an
    application error if two clients attempted to invoke the same session object.

    So you should not use the same EJB from different client threads!!

  3. Thanks. This is what read too (the question was asked on my behalf). Next question, which is related:

    Since we cannot directly reference the Bean from multiple sources, an alternative would be to pass the state into the business class. We do this now for synchronous work (pretty standard coding). However, this particular process will run in a thread controlled by a thread engine. The (real) client will be polling for status from the EJB, which will in turn query the thread engine. Therefore, the workflow remains synchronous, but the actual work is not. Is there a known danger of updating the bean's state in such conditions? The state is represented by a standard compound java object. This means there are at least 2 references to the same data: the EJB and the thread engine. I suspect we need to at least make that compound object synchronized to address any risk of simultaneous access.

    If the above scenario is not kosher, then are there any other suggestions for asynchronous work that updates state? I'm already considering having the thread write data directly to UDB rather than update the EJB state. However, that means I'll have to tell the EJB to refresh itself from UDB as soon as the work is done.

  4. Hi

    Are you writing a Swing client, and want quicker response to end-users by doing parts of the work in separate threads?

    Sharing the state in a synchronized compound Java object can introduce problems if the processes (client, EJB, and thread manager) are running in different JVM:s. Also note that the call from non-EJB client to and EJB (and between non-local EJB:s) always create a copy of the state-holding object.

    Another idea is to keep the state is an Entity Bean! All threads (and different types of clients) can share data in the entity, and your EJB server is fully responsible for refreshing the state between different clients! (If one client changes persistent data/state, other clients will know of the new data directly.) The EJB container will also do the synchronization for you! When you don't need to keep the state anymore, you can remove the state-keeping Entity Bean.

    This solution may introduce performance problems if you have many clients working on the same server. On the other hand, using SFSB also rise some performance issues.

    I think there is one more question in this problem: Do all threads need to know changes in state, or is it OK to work with copies (snapshots) of state?