db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Jefferson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-590) Control over transaction isolation level
Date Sat, 13 Sep 2008 07:28:44 GMT

    [ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630734#action_12630734
] 

Andy Jefferson commented on JDO-590:
------------------------------------

Only comment on the patch is that PMF.getSupportedOptions() javadoc likely needs to include
the possible transaction isolation values
javax.jdo.option.TransactionIsolationLevel.read-committed
javax.jdo.option.TransactionIsolationLevel.read-uncommitted
javax.jdo.option.TransactionIsolationLevel.repeatable-read
javax.jdo.option.TransactionIsolationLevel.snapshot
javax.jdo.option.TransactionIsolationLevel.serializable

Also, within that method javadoc there is some mysterious option "javax.jdo.option.NonDatastoreIdentity"
Probably should be "javax.jdo.option.NonDurableIdentity"

> 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
>
>         Attachments: jdo-590.patch
>
>
> 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.


Mime
View raw message