Sorry, I forgot to add the following fact - which will be of MOST interest obviously:

- analysing the logfiles where the conflicting TXs occur, it seems that there are currently 2 THREAD RUNNING IN PARALLEL.
- each thread is working on definitely different data, so a deadlock should not really be possible

but I think I can remember that somebody mentioned that OpenJPA is not safe for multithreaded usage by default and that
some special parameter has to be set in perstence.xml ? But if I understood the discussion right, this was just if different
EMF's are using multithreaded, not the EM's - that's why I did not yet activate this multithreaded feature.

Is this also the case for the behaviour I described? (application managed JPA, outside a java ee 5 container, but running inside
a java ee 1.4 container utilizing its JTA managed transactions; multithreaded environment).

any ideas?


Am Mittwoch, den 28.03.2007, 20:47 +0200 schrieb Hans J. Prueller:
Hi together,

I succeeded in integrating OpenJPA into our J2EE1.4 container, running side-by-side within the same JTA transactions as
container managed EJB2.1 CMP entity beans.

The lookup/creation of the EntityManager instances is synchronizing with the JTA TXs as you suggested some weeks ago
on this list.

After having a test server up and running for some days, we are encountering lots of those messages:

WARNING: Connection not closed by caller

Suddenly (some hours later), a transactions fails:

2007-03-27 14:57:07,097 : WARNING :  Logger.log :    Conflict with bb14:38:0:01fb60a716b0bed67c...80c679:
2007-03-27 14:57:07,113 : WARNING :  Logger.log :    Current Tx is bb14:38:0:01fb60a716b0bed67c...32a266:
2007-03-27 14:57:07,144 : WARNING :  Logger.log :    You should not modify the bean without a transactional context

2007-03-27 14:57:07,160 : SEVERE :  Logger.log :    system exception in business method:javax.ejb.EJBException: Conflict writing entity bean

Somehow this HAS to be related to the OpenJPA integration, but the server was up for at least a day and running fine until above error
occured. Any idea how this bad conflict could be caused?