[
https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629251#action_12629251
]
Andy Jefferson commented on JDO-590:
------------------------------------
Agreed, they be better off knowing it. But then we could make available
String[] Transaction.getSupportedIsolationLevels();
so they have everything in their hands to avoid it :-)
So
Transaction.setIsolationLevel(...)
PMF.setTransactionIsolationLevel(...)
would throw a JDOUserException on unsupported level. What if the PMF property
(javax.jdo.option.TransactionIsolationLevel) was specified with an unsupported
level ? Maybe throw a JDOUserException at PMF creation.
> 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.
