|
Home > Archive > Apache JDO Project > April 2007 > DatastoreConnection / optimistic txs
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
DatastoreConnection / optimistic txs
|
|
| Erik Bengtson 2007-04-08, 1:11 pm |
| I have an optimistic transaction and I access the datastore connection. I
perform some updates/inserts and rollback the transaction. The changes are not
rolled back since the connection/transaction was not enlisted in the JDO
optimistic transaction. This behavior is correct according the below paragraph
from the spec, but I disagree.
This behavior is mainly addressed to the optimization the JDO implementations do
(releasing connections if it was only used to read - avoid locks), and SELECTs
performed in native connection. It does not take into account the possibility
of performing UPDATEs, INSERTs or DELETEs.
I propose of changing this behavior and mandate enlisted of connections if a JDO
transaction is open, datastore or optimistic.
"12.16 Access to internal datastore connection
If called in an optimistic transaction before flush has
been called, or outside an active transaction, the object returned will not be
enlisted in any transaction."
| |
| Craig L Russell 2007-04-08, 1:11 pm |
| | |
| Erik Bengtson 2007-04-08, 1:11 pm |
| Quoting Craig L Russell <Craig.Russell@Sun.COM>:
> This is a backward-incompatible change. But maybe we should consider
> to request a datastore connection that would have that semantic by
> adding a boolean flag to the getDataStoreConnection method indicating
> that you want to be able to perform transactional updates with it.
>
Contractually speaking this change is incompatible, but it's undetermined when
flush gets first called by the JDO implementation, so this feature is not
portable.
| |
| Craig L Russell 2007-04-08, 1:11 pm |
| | |
| Erik Bengtson 2007-04-08, 1:11 pm |
| > I'm afraid I don't know what you mean by "this feature" and "this
> change". If you want to guarantee that the datastore connection you
> get is enlisted in the JDO transaction
tx.setOptimistic(true)
tx.begin()
//do some operations here
JDOConnection conn = tx.getDataStoreConnection();
conn.getNativeConnection().execute("UPDATE TABLEB SET A=1");
conn.close();
tx.rollback();
A flush may or may not be performed before "getDataStoreConnection" gets
invoked. If a flush is performed, the connection is enlisted in the
transaction.
So, accessing the datastore connection and doing updates is not portable, since
the connection may or may not be enlisted in the transaction.
The side effect of my change proposal would make it portable since connections
are always enlisted in the transaction 
> we can add a flag to guarantee it.
I'm in favor of breaking backward compatibility and not adding a new flag,
because currently it's not ACID neither portable.
| |
| Craig L Russell 2007-04-08, 7:11 pm |
| |
|
|
|
|