Hi,It's my belief that if OpenJPA is configured to use a datastore transaction, then a commit will occur in this situation, but if using optimistic transactions, the commit will not occur unless OpenJPA believes that something noteworthy has happened during the transaction.
Additionally, in default configurations in a RESOURCE_LOCAL environment, ConnectionRetainMode is set to on-demand, so OpenJPA might well use multiple different connections over the course of a given JPA transaction.
-Patrick On May 30, 2008, at 3: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.
-- Patrick Linskey 202 669 5907
smime.p7s
Description: S/MIME cryptographic signature
