Stateful Session Bean dilema

[jlbakker]

Hi all,

I an maintaining somebody's piece of software/prototype that is supposed to process multiple HTTP requests coming from multiple clients. It is designed like this: there is one servlet that gets a reference to a SFSB upon the first/initial request of a client and stores that SFSB in a Map. Subsequent requests of the same client can be identified by the key. The servlet retrieves the SFSB using the key in the URL upon a 'subsequent' request.

So the SFSB is designed to be stateful even between subsequent requests.

Now, I put this to test and fired two initial requests at the servlet and two SFSBs were created. Yet, soon concurrent access occured and it failed with a dreaded transaction context violation exception. The solution is to synchronize access to the SFSB.

In my mind, this is not concurrent access as two beans were created via the Home interface. Synchronization is not the answer as it essentially means every request will have to wait for the other request to complete. Should I make SFSB stateless? Why? I still think that I have two SFSB instances thus two requests should be handled in parallel.

Regards,

John-Luc

[joelvogt]

well sort of, what are you actually doing with the stateful beans? Are you doing updates or deletes etc?

[jlbakker]

As far as I can see the methods I invoke are read-only operations.

Thanks,

John-Luc

[jlbakker]

Hi Joel and others,

I really like to understand why I cannot have one thread per SFSB simultaneously. Is it a JBOSS or EJB limitation? Is it specified in the EJB spec.? Any pointers appreciated!

Best regards,

John-Luc

[sgturner]

You said that the SFSBs are stored in a Map. Maps are not thread safe and I am assuming that all requests have access to this Map. That may be the source of your problem. Why not store the SFSB in the HttpSession object? SFSB are not meant to be used asynchronously.

[jlbakker]

Thanks. Meanwhile I have changed the code such that the bean is now stateless; the state is stored in the URL accessing the servlet. A stateless bean is the preferred solution anyway. I will have a look at HttpSession objects and see how they may make things easier!

Your suggestion that the error may be caused by the Map may also be true; as I once noticed exceptions in odd places with a not so stateless stateless session bean. Thus, there is no architectural or JBoss reason why each SFSB could not be accessed by its own thread, simultaneously. I agree that in my case (and perhaps in most cases) SFSBs should be avoided.

Thanks again!

John-Luc