openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Linskey <>
Subject Re: commit
Date Thu, 29 May 2008 21:30:28 GMT

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.


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

View raw message