Good observation. Please file a JIRA and a test case.
Seems like OpenJPA should keep track of whether a jdbc Connection was ever acquired by the transaction. Not sure how to know whether read locks were acquired...
So are you suggesting that OpenJPA should *always* commit the transaction?
Craig On May 29, 2008, at 10:14 AM, David Wisneski wrote:
I appears that when running in a RESOURCE_LOCAL environment with a nonJTA datasource, in either J2EE or J2SE, when an application calls EntityManager.getEntityTransaction().commit() a sql commit may or may not actually occur. If there are no updated objects flushed to the database, then the commit is quietly ignored. However, the user may be holding read locks if the transactionIsolation was repeatable-read and these locks will not be released. The user may have done nativeSQL which may or may not have done updates or the user may have obtained the connection from the Broker and have done his or her own sql directly to the database. OpenJPA is being too aggressive in its optimization of commits (and rollbacks) and this may need to be disabled or scaled back. We are seeing locking and deadlock problems where there should be none.
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
