openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "catalina wei" <>
Subject Re: commit
Date Fri, 30 May 2008 19:25:41 GMT
Correction on my previous remark:
The re-read is on the version field. not entire row  (i.e. SELECT


On Fri, May 30, 2008 at 10:42 AM, catalina wei <>

> Hi,
> 1.Set openjpa.ConnectionRetainMode to "transaction" helped eliminating
> connection close after  SQL statement.
>   this property alone has no impact on user transaction commit request.
> The commit is optimized away if there is no updates to any transactional
> objects because the openjpa.Optimistic default is "true".
> 2. set openjpa.Optimistic to "false":
>  this property setting not only retains the connection, but also honors
> user transaction commit request;
> connection is only closed after transaction commits.
> But there is performance penalty -- all transaction objects in the context
> will be re-read from the datastore, even if there is no updates.
> Questions:
> 1. what is the right set of the properties that users should use for
> applications that run with default JDBC transaction isolatioin level = 8
> 2. Should OpenJPA detect that the default setting (Optimistic = true)
> conflicting with JDBC's default and do something about it?
> Catalina
> On Thu, May 29, 2008 at 2:30 PM, Patrick Linskey <>
> wrote:
>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message