Our impl is a proxy that delegates to an EM instance stored in a TransactionLocal. So, at least on a per transaction basis, there is safety. Whether or not a Hibernate Session is thread safe, I don't know...
A Hibernate Session is certainly not threadsafe. But there is one per transaction, and one transaction per thread. So the overall model is threadafe.
Also note that SLSB instances are actually single threaded.
Thanks for the reply guys,
I hadn't realized that SLSB was single threaded. So, more instances get created with concurrent requests? Or all requests get processed serially?
I ask because I made the (apprearantly incorrect) assumption that SLSB was accessed concurrently and implemented our site's authentication system as a SLSB that gets injected into our MDBs.
Basically it's an AJAX style site where a requests go browser -> servlet -> JMS -> MDB (auth, process request, update db, use various injected SLSBs, etc) -> JMS -> servlet -> browser.
When concurrent hits occur, we sometimes get weird interractions.
As well sometimes it seems like @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) doesn't always work.
We'll force a store by calling a store() method annotated as above, then send a message to another module who fails to find it in the DB.
Doesn't always happen, it's either random, or something weird going on.
I do know that I can't seem to get SonicMQ connections enrolled in JBoss JTA (I'm assuming because I'm not using the real JCA adapter they wrote due to them requiring me to hack up standard-jboss.xml which is scarry when using EJB3)
Anywho, more than you wanted to know there.
Thanks for the response again guys, I'll investigate further into our issues.
session beans are pooled, so you set the number of SLSB instances available in it