openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: commit
Date Thu, 29 May 2008 19:43:14 GMT
Okay, I just got confirmation from a reliable source :-) that close() does
not require an implicit commit or rollback action.  It's provider specific.
Most implementations will do either a commit or rollback of any outstanding
transactions, but it is not a requirement.  In this particular case, it
looks like Informix is one of those implementations that does nothing to
outstanding transactions at close.

So, I think we're back to removing the commit optimization that we have in
OpenJPA.  If commit (or rollback) is invoked on the EntityTransaction
interface, then we should pass that onto to the jdbc driver to let it do
it's thing.

Kevin

On Thu, May 29, 2008 at 2:29 PM, Kevin Sutter <kwsutter@gmail.com> wrote:

> Dave,
> Another thought...  You say that OpenJPA is performing the close() on the
> connection.  Doesn't the close() either commit or rollback any pending
> transactions?  I know this can differ from provider to provider, but what is
> happening in your scenario?  It would seem that if the close() is happening,
> the jdbc provider should be cleaning up the connection (along with any
> locks) before releasing it to the pool.
>
> Kevin
>
>
> On Thu, May 29, 2008 at 2:10 PM, Kevin Sutter <kwsutter@gmail.com> wrote:
>
>> Dave,
>> I agree that OpenJPA should not be optimizing out this commit call.  We
>> should fix that in the OpenJPA code.
>>
>> OpenJPA does not pool connections.  In this particular scenario, the
>> pooling is performed by WebSphere.  So, the last part of your comment is
>> related to how the Connection Manager (for whatever app server environment)
>> processes the non-jta-data-sources.
>>
>> Kevin
>>
>>
>> On Thu, May 29, 2008 at 1:32 PM, David Wisneski <wisneskid@gmail.com>
>> wrote:
>>
>>> If the user call EntityTransaction.commit(),  I think that OpenJPA
>>> should definitely issue a commit.   Another related problems, is that
>>> OpenJPA is closing the connection and putting it back into the free
>>> pool after every sql statement,  even if there are still read locks
>>> being held by the active transaction.    This would be OK if the user
>>> does a EntityManager operation outside a transaction scope,  but it
>>> should not be occurring when the user has explicitly done an
>>> EntityTransaction.begin().
>>>
>>>
>>> On 5/29/08, Craig L Russell <Craig.Russell@sun.com> wrote:
>>> > 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:Craig.Russell@sun.com
>>> > P.S. A good JDO? O, Gasp!
>>> >
>>> >
>>> >
>>>
>>
>>
>

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