openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: commit
Date Thu, 29 May 2008 21:18:48 GMT
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!


Mime
View raw message