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 17:42:06 GMT
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.

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?


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