You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by "Craig Russell (JIRA)" <ji...@apache.org> on 2008/08/29 18:12:45 UTC
[jira] Assigned: (JDO-590) Control over transaction isolation level
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell reassigned JDO-590:
---------------------------------
Assignee: Craig Russell
> 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, api2-legacy, specification, tck2, tck2-legacy
> Reporter: Andy Jefferson
> Assignee: Craig Russell
> 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.