There is an technology stack: Java EE (WebSpere), JPA, EJB3, JMS (MDB), JSF.
Architecture: JMS messages arrive (via MDB) and are registered as persisted entities – (using EntityManager). There is a Singleton class with infinite loop which is responsible for processing of those entities. The Singleton is notified about created entities by MDB. Initially entities are stored in queue inside the Singleton. Created entity can be processed up to several minutes. No more than certain amount of entities can be processed simultaneously (several parallel processes in Singleton). The Singleton is not an EJB, but there are EJB services used by it. There is a class which represents Execution Context for given entity (simple DTO). The Execution Context holds dependencies on needed EJBs and is created on MDB interaction step and passed to the Singleton service along with notification a new message (basically MDB has annotated injections of those EJBs and EM, and creates new Execution Context passing those injected instances).
The problem is: processing of an entity is started but EntityManager at some point of time (after a few seconds) begins returning nulls for search requests, and it should not, as just a second ago the entity was updated.
It looks like the architecture is not good. I suspect that the EM’s behavior is a sign that persistence context has gone after some time after interaction between MDB and the Singleton has done.
Singleton has life time much longer than life time of any managed bean in system. So, injection of EJB instances (and EM instance) to such component seems not to be a solution at all (passing references to injected EJB instances from MDB to the Singleton probably is a worst decision).
Probably EJB, as well as EM should be looked up by the Singleton using JNDI each time they are needed?
In this case, should I lockup the EJBs for each call?
Which way would you design the system: if MDB only registered message (as entities). And processing of entities may start latter. And you have to use some EJB services (local interface). And there is Entity Manager as well.
If the entity manager that the Singleton is using is transaction scoped, then the lifetime of the Singleton doesn’t matter. In a way, stateless session beans also have an infinite lifetime once created (their scope is essentially ‘none’, but their instances are pooled and kept being re-used).
Every time the method in the singleton services a request, a new transaction is started and a new persistence context is piggy-backed to that, even though the entity manager instance seems to be the same throughout those requests. This is normal behavior and should not ‘suddenly’ return nulls.
It might be worth checking if your singleton is using appropriate locks. If the entity manager is accessed concurrently then this may be the cause of undefined behavior.