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 Sun, 08 Jun 2008 23:37:26 GMT
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


Mime
View raw message