Re: commit

-Original Message- > > From: Patrick Linskey [mailto:[EMAIL PROTECTED] > > Sent: Monday, 9 June 2008 3:11 p.m. > > To: dev@openjpa.apache.org > > Subject: Re: commit > > > > Hi, > > > > > Putting connections with active transactions into a fre

RE: commit

Is this for the Java SE case, or the container-managed case? > -Original Message- > From: Patrick Linskey [mailto:[EMAIL PROTECTED] > Sent: Monday, 9 June 2008 3:11 p.m. > To: dev@openjpa.apache.org > Subject: Re: commit > > Hi, > > > Putting connections w

Re: commit

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

RE: commit

atrick Linskey [mailto:[EMAIL PROTECTED] > 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 th

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

Re: commit

Correction on my previous remark: The re-read is on the version field. not entire row (i.e. SELECT t0.version...). Catalina On Fri, May 30, 2008 at 10:42 AM, catalina wei <[EMAIL PROTECTED]> wrote: > Hi, > 1.Set openjpa.ConnectionRetainMode to "transaction" helped eliminating > connection close

Re: commit

Hi, 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

Re: commit

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,

Re: commit

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

Re: commit

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 hold

Re: commit

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

Re: commit

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 happe

Re: commit

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 (fo

Re: commit

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 t

Re: commit

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?