Kieran Simpson [http://community.jboss.org/people/kierans] created the discussion "Why do EJBs share EntityManager instances" To view the discussion, visit: http://community.jboss.org/message/574182#574182 -------------------------------------------------------------- In the application I am developing, the input comes from a Seam UI, where messages are placed onto a JMS queue to be processed asynchronously.  Since multiple users can use the UI concurrently, multiple messages can be processed concurrently by the backends MDB/EJBs. The DAO layer is comprised of a Stateless Session Bean with the EntityManager being injected via the @PersistenceContext annotation.  When a message is polled from the queue and processed, the top level EJB coordinator for the processing starts a new transaction via the REQUIRES_NEW TransactionAttributeType.  However when one thread encounters a DB error, the shared EntityManager rolls back all transactions, thus the other threads fail.  I've done a heap dump analysis with Visual VM and I can see that my DAO instances all are being injected with the one instance of TransactionScopedEntityManager. Reading the http://docs.jboss.org/hibernate/entitymanager/3.5/reference/en/html/trans... Hibernate docs, the EntityManager is not thread safe.  Doing a lot of Googling I'm seeing a lot of other forum posts on this subject, however a lot of the material is years old and thus could be outdated. Why doesn't JBoss do a similar SharedEntityManager idea like that of Spring, or OC4J?  Surely it would be a good idea to have code abstracting away the threading concerns of EntityManagers by injecting a wrapper that is thread safe, and that delegates to underlying Hibernate EntityManagers. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/574182#574182] Start a new discussion in EJB3 at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]