Hello!

I'm still new to hibernate and not sure is this the right place for a question that might better belong to a JBoss Forum (I'm working with JBoss 3 and the EJB 3 addition).

My problem is the following: An entity is created in a MessageBean (A) and persisted via an injected EntityManager. Next (A) sends messages to other MessageBeans (B's) that have to use the created bean. As long as all B's are working, (A) is caught in a loop and will not return from its onMessage()-Method. While (A) still is running, an instance of (B) now tries to call EntityManager.find() with the id of the entity on another EntityManager with same PersistenceContext, but this method returns null... why?
I expected that two injected EntityManagers in the same PersistenceContext share their information, but I did not find any way to realize that.
Calling flush() on the EntityManager in (A) does not solve the problem, neither did modifying the TransactionContext of the persisting Method in (A) nor to create a new entity with same id and call em.refresh() or em.merge()...

The only way I found to solve this Problem was to create an EntityManager by a Factory and explicitely call "commit()" after persisting the entity. Unfortunately, this makes the application very slow, because every modification is sent to the database immediately.
Is it possible to modify the behaviour of the EntityManagers the way I need? Is there any property that one can set in hibernate's configuration to do so?

It would be great if someone could help me and/or give me some hint where to find a solution...

Thanks,
Stephan

Why are you thinking the persistence context should be shared between the 2 calls?

You're right - I guess I got the wrong idea about persistence contexts.

First of all, the problem I tried to explain is solved - with the TransactionAttribute REQUIRES_NEW used in Bean (A) the EntityManager in (B) does not return null anymore. I thought I was testing this attribute before I posted my question, but obviously I did not or I made some other mistake... sorry for that!

Now there's much less need for a shared persistence context... what I was expecting from sharing persistence context was that it could make the application faster by doing less commits and instead using the shared context (or a shared EntityManager) as some kind of cache. Í did not realize that this idea would not work when there's more than one virtual machine (or, maybe, expecting that the EntityManager will take care of all of that...). Our application might not be typically for J2EE - in fact, transactions are not very important, because data is written only once but than read/queried often, so it would not be neccessary to store it in the database as long as there is enough RAM available - under these circumstances it could make sense to share data that only has been persisted by an EntityManager, but not yet committed to the db, over several parallel working MDBs.

Thanks for the time you spend in reading strange newbie questions,
Stephan

You objects will have to be thread safe then. The only safe choice I can see is to create your own object queue somewhere and take care of this shared cache yourself.