>>Sometimes when ejbTimeout returns, there is no error for persist(D), but the data is not stored in the database.
--> sounds like flush has not been performed, which is indeed strange
I've tried calling entityManager.flush() after the persist call, but it had no effect.
>>Sometimes I've seen a transaction start, but not complete. After this, I cannot modify the row I'm trying to persist in D from outside GF until I exit GF.
--> row is indeed locked until transaction is committed or aborted
Yes, but my understanding is that since B is a Bean with a local interface and is being called via it's Local interface, that the PersistenceContext (set using the annotation) and EntityManager are used and that, upon exit of the method defined in the Local interface, the commit is performed. So I don't understand why I don't see the data change in the database.
I don't understand well what is the relation between the MDB delivery and the Timer? I guess that when a message is delivered, A calls B to register a new Timer? Are you passing information in the Timer itself? Or is the row to update a fixed one? Which version of Glassfish are you using? Are you using Oracle Toplink for JPA?
The MDB is really the "main" class for the application. It also happens to implement the TimedObject interface. I actually have 2 "B"-type classes which I need to call methods on when ejbTimeout is called (though I'm only calling one now until I resolve this issue), so I'm using the MDB as the timer entry point. Tonight I'll create a TimerManager class and move the timer code there and out of the MDB. However, I don't hold much hope that this will solve my problem.
When a message is delivered, the MDB processes separate code...nothing to do with B.
I am passing nothing to the timer.
Not sure what you mean by "row to update is a fixed one".
Glassfish v2u2 using Oracle Toplink
[Message sent by forum member 'darryl_m' (darryl.mocek_at_sun.com)]
http://forums.java.net/jive/thread.jspa?messageID=368493