Control over transaction isolation level
----------------------------------------
Key: JDO-590
URL: https://issues.apache.org/jira/browse/JDO-590
Project: JDO
Issue Type: New Feature
Components: api2
Reporter: Andy Jefferson
Fix For: JDO 2 maintenance release 2
There are 2 sides to this :-
1). Standardising a mechanism for specifying the transaction isolation level.
This is the primary thing I am referring to, and to do that we need to provide
a notional
set of isolation levels - not necessarily just the JDBC set, but that was the
start point as a basis for comment. As mentioned in other docs (see
http://www.cs.umb.edu/~poneil/iso.pdf )
the JDBC set is not complete for our scope, and other totally valid levels
should be part of it. In some parts
of the JDO interface (e.g value generation) we define some values, and then
allow implementations to add on their own additional values if not catered
for in the defined list. This is what I would envisage. Suggested levels
NONE, READ_UNCOMMITTED, READ_COMMITTED, NO_LOST_UPDATES, REPEATABLE_READ,
SERIALIZABLE
2). Standardising support for these levels in the JDO implementation, so that
the user is always guaranteed to be able to use what they specify. I'm not
proposing this at all, and see that as unrealistic for an impl to provide
anyway. I simply propose that if an underlying datastore doesn't support the
level specified then we throw an exception, hence the user always knows if
their isolation level is going to be used. This is very much in line with
other parts of the JDO spec where the implementation is free to support some
or all of the valid values.
Obviously, where the underlying datastore supports multiple levels then it
provides value for the user. Similarly where the underlying datastore
supports only a single level then it is something that user would have no
need to change.
jdo-dev mailing list : Christian Romberg wrote
we have to distinguish optimistic and datastore transactions in this
discussion, and also what we want to achieve. Personally I think, we want to
provide some behaviour guarantees of the API. Unfortunately, this is not the
approach used by SQL for defining isolation levels.
So for datastore transactions it simply does not work, because one backend
might be a versioning database while another is a non-versioning database, and
the behaviour will be totally different, although both guarantee the same
isolation level.
On the other hand with JDO optimistic transactions, the behaviour is quite
consistent right now (unless flushing is involved), but only a two levels make
sense: READ_UNCOMMITTED NO_LOST_UPDATES
all other levels are either unachievable or implicitly overachieved.
However, if we want to provide REPEATABLE_READ, then we could do so in that we
implicitly include all read (but not modified) objects in the set of objects
checked for modifications at commit time.
Currently a user can do that, by calling "makeTransactional" on read objects.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
