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 freepool. So there might be too problems here -- 1. JPA is not doing acommit. 2 pooling is putting connections with active transactions holding locks into the free pool. On 5/29/08, Kevin Sutter <[EMAIL PROTECTED]> 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 tooutstanding 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 doit's thing. KevinOn Thu, May 29, 2008 at 2:29 PM, Kevin Sutter <[EMAIL PROTECTED]> 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 anylocks) before releasing it to the pool. KevinOn Thu, May 29, 2008 at 2:10 PM, Kevin Sutter <[EMAIL PROTECTED]> wrote:Dave,I agree that OpenJPA should not be optimizing out this commit call. Weshould 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. KevinOn Thu, May 29, 2008 at 1:32 PM, David Wisneski <[EMAIL PROTECTED] >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 itshould not be occurring when the user has explicitly done an EntityTransaction.begin(). On 5/29/08, Craig L Russell <[EMAIL PROTECTED]> wrote:Good observation. Please file a JIRA and a test case.Seems like OpenJPA should keep track of whether a jdbc Connection waseveracquired by the transaction. Not sure how to know whether read lockswereacquired... So are you suggesting that OpenJPA should *always* commit thetransaction?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 callsEntityManager.getEntityTransaction().commit() a sqlcommit may or maynot actually occur. If there are no updated objects flushed to the database, then the commit is quietly ignored. However, the usermaybe holding read locks if the transactionIsolation was repeatable-readand these locks will not be released. The user may have donenativeSQL 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 ownsql 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
-- Patrick Linskey 202 669 5907
smime.p7s
Description: S/MIME cryptographic signature
