openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Linskey <plins...@gmail.com>
Subject Re: commit
Date Mon, 09 Jun 2008 03:11:13 GMT
Hi,

> Putting connections with active transactions into a free pool is an  
> error,
> regardless of whether the active transactions hold locks or not.

My understanding is that the issue at hand is around the behavior of  
connection retention within a given transaction, not the validity of  
the connection pool.

I definitely agree that the connection pool should never have  
connections associated with active transactions in them.

-Patrick

On Jun 9, 2008, at 12:23 PM, Evan Ireland wrote:

> Putting connections with active transactions into a free pool is an  
> error,
> regardless of whether the active transactions hold locks or not.
>
> Perhaps the underlying issue here has nothing to do with locks per  
> se, but
> just connection/pool management.
>
>> -----Original Message-----
>> From: Patrick Linskey [mailto:plinskey@gmail.com]
>> Sent: Monday, 9 June 2008 11:37 a.m.
>> To: dev@openjpa.apache.org
>> Subject: Re: commit
>>
>> Hi,
>>
>> The JPA 1.0 spec only defines em.lock() in terms of optimistic
>> locking, so the behavior wrt. connections is undefined (I contend  
>> that
>> optimistic locking can be implemented per the spec with no connection
>> affinity until the very end of the transaction).
>>
>> Under the new JPA 2.0 datastore locking semantics, the connection  
>> used
>> to obtain the lock will need to be retained for the duration of the
>> transaction.
>>
>> When configured to do datastore locking, current versions of OpenJPA
>> should be retaining the connection after an appropriate lock() call.
>>
>> -Patrick
>>
>> On May 30, 2008, at 7:18 AM, Craig L Russell wrote:
>>
>>> Hi David,
>>>
>>> You bring up a good point, that in JPA the assumption is that until
>>> commit, the provider can get a pooled connection and then return it
>>> to the pool after it does whatever it likes.
>>>
>>> Except after a lock is acquired explicitly via the em.lock method,
>>> which implies (to me) that the user wants to hold locks until the
>>> transaction is over. And the connection used to acquire the lock is
>>> no longer eligible to be put back into the pool.
>>>
>>> Is this your understanding?
>>>
>>> Craig
>>>
>>> On May 29, 2008, at 1:09 PM, David Wisneski wrote:
>>>
>>>> When JPA does a close, because of connection pooling,  this does  
>>>> not
>>>> necessarily result in a close to the databsae.   JPA is issueing a
>>>> close (without a commit or rollback) and connection pooling is just
>>>> returning the connection to the free pool (without a commit or
>>>> rollback).  So a connection holding read locks is now is the free
>>>> pool.    So there might be too problems here -- 1.  JPA is not
>>>> doing a
>>>> commit.  2  pooling is putting connections with active transactions
>>>> holding locks into the free pool.
>>>>
>>>>
>>>> On 5/29/08, Kevin Sutter <kwsutter@gmail.com> wrote:
>>>>> 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!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>> 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!
>>>
>>
>> --
>> Patrick Linskey
>> 202 669 5907
>
>

-- 
Patrick Linskey
202 669 5907


Mime
View raw message