Re: enlistment of native connections for optimistic txs

[Craig L Russell]

Hi Erik,

Thanks for clarifying your proposal.







<proposed>
Connection getDataStoreConnection()

This method is equivalent to getDataStoreConnection(true).

Connection getDataStoreConnection(boolean enlist)


transaction, regardless of the setting of the enlist parameter.






</proposed>

Craig

On Apr 8, 2007, at 1:49 PM, Erik Bengtson wrote:

I agree that this improves portability, but with a penalty. You can no longer use optimistic concurrency once you decide to do some native SQL, even if you don't ever perform any INSERT, DELETE, or UPDATE statements. And this will have negative performance consequences for some applications. While backward compatibility is important, I would agree with you that correctness is even more important. So it doesn't bother me too much if we change the semantic so that by default, getting a datastore connection is equivalent to doing a flush in an optimistic transaction. But I'd still like to give the user the ability to get the same level of performance they now enjoy by deferring the enlistment in the datastore transaction to flush or commit. So how about adding a flag that defaults to true if not specified to enlist the datastore connection in the datastore transaction? If this method is called outside an active transaction, the object returned will not be enlisted in any If it is called while a datastore transaction is active, the object returned will be enlisted in the current transaction, regardless of the setting of the enlist parameter. If it is called while an optimistic transaction is active, and the enlist parameter is true, a datastore transaction is begun if not already begun, and the object returned will be enlisted in the current datastore transaction. If it is called while an optimistic transaction is active, the enlist parameter is false, and a datastore transaction is already begun, the object returned will be enlisted in the datastore transaction. If it is called while an optimistic transaction is active, the enlist parameter is false, and a datastore transaction is not already begun, the object returned will not be enlisted in any datastore transaction.

Hi,


connections when optimistic transactions are used.


the fact that a flush call has been performed before the connection is
obtained.


different implementations. See the example:

1. tx.begin();
2. //more operations here....
3. JDOConnection conn = pm.getDataStoreConnection();
4. Connection sqlconn = (Connection) conn.getNativeConnection();
5. sqlconn.execute("DELETE FROM ANIMAL WHERE NAME = 'CAT'")
5. conn.close();
6. tx.rollback();

There are two possible behaviors:


connection is enlisted, and DELETE all CATS from ANIMAL is rolled back




The change is to the following paragraph:

The JDO spec §12.16 - getDataStoreConnection:


returned will be enlisted in the current transaction. If called in an


AS:


transaction."

This is a change proposal to the spec with regards to enlistment of native The enlistment of native connections into a JDO transaction is conditioned to The flush call is a JDO implementation decision which can differ between - The JDO implementation decides to perform a flush between 1 and 3: the - The JDO implementation decides to NOT perform a flush between 1 and 3: the connection is not enlisted, and DELETE all CATS from ANIMAL is not rolled back As you can see, this is not portable and not ACID, so I would like to propose that enlistment of connections is done whenever a transaction is opened. "If this method is called while a datastore transaction is active, the object optimistic transaction before flush has been called, or outside an active transaction, the object returned will not be enlisted in any transaction." "If this method is called while a datastore or optimistc transaction is active, the object returned will be enlisted in the current transaction. If called outside an active transaction, the object returned will not be enlisted in any

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!

smime.p7s
Description: S/MIME cryptographic signature