Hi,

After spending the whole week trying to fix this problem, i am still no closer to the actual solution but i have discovered some more information. This problem is Postgres specific at the moment as i have tested the EntityManager.find() method call in the same context when using Hypersonic and MySQL and the entity is always found.

After studying the log file created by Postgres (without having the 2 second delay) it seems to not be able to commit the initiial insert statement generated from the EntityManager.persist() call before it tries to query it with the select statement, thus the .find() returns null. The thing that worries me about this problem is that some times it works with Postgres, and that it always works with the 2 other databases i tested with.

I have read up on the EntityManager and discovered that it is not thread safe, could this be causing the problem with Postgres, if so i know i need to use an EntityManagerFactory as this is a thread safe object, but how do i just create on factory that the whole of the application can use (be used in different beans, possible JNDI lookup ??), and even then i do not know if this would solve my problem. Is there anyway of making the EntityManager.persist() method wait until the database has actually commited before it returns ??? I have also tried to introduce flush() calls but they do not solve the problem.

Is this a possible bug in the EntityManager or Postgres JDBC code ???

I also have a very simple test application (.ear file) that just persists some bytes to a database and then tries to find them again in a seperate MDB, and then prints out if it cannot find the persisted object. If anybody wants it to test the problem with this application i will make it available to them.


If anyone can help, or offer advice it is appreciated.

Cheers,

Andy

Yesterday we managed to get it working with pure JDBC without any problems. We then integrated the EntityManager with the JDBC statements, and we think the problem exists with the .persist() method. It seems as if it returns from the method without waiting for the commit to happen at the database level.

Andy

Karma,

I found that annotating the class (where the data is persisted) with @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) solved the problem for me, but unfortunately it does not seem to work for you. But after reading your post i have revisited the problem and removed the annotations and it still works !!! so i really don't know what the cause of problem was in the first place.

I would imagine that the underlying cause of the problem i had will be the same as the problem you are currently experiencing, namely that the em.persist() only triggers an update and does not wait for the transaction to commit, and i also found that trying em.flush() after had no effect at all. To see if that is the case turn on full database logging and you should see the insert, select, and then commit in that order.

The current program layout i have that is working is to have a top level method that calls 2 other methods. Method 1 is the presist data method and method 2 is the send message method. See below:

public void action(){

 int pk = 0;

 try{
 pk = doPersistData();
 }catch(Exception e){
 e.printStackTrace();
 }

 try{
 // send a JMS message
 doMessageStuff(pk);
 }catch(Exception e){
 e.printStackTrace();
 }
 }