[jira] Commented: (JDO-590) Control over transaction isolation level

["Craig Russell (JIRA)" <ji...@apache.org>]

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

Craig Russell commented on JDO-590:
-----------------------------------

If we agree that the mechanism for specifying transaction isolation is useful, we have a window to put it in. Here's what I'd propose as an API:

Constants.java
public static final String TX_READ_UNCOMMITTED = "read-uncommitted";
public static final String TX_READ_COMMITTED = "read-committed";
public static final String TX_REPEATABLE_READ = "repeatable-read";
public static final String TX_SNAPSHOT = "snapshot";
public static final String TX_SERIALIZABLE = "serializable";

>From Andy's comments,
<andy>
javax.jdo.Transaction 
void setIsolationLevel(String level); 
String getIsolationLevel(); 

javax.jdo.PersistenceManagerFactory 
void setTransactionIsolation(String); 
String getTransactionIsolation(); 

Add a PMF property 
javax.jdo.option.TransactionIsolation that allows definition of the default value to use, again using a String). 
</andy>

Add an attribute to persistence-manager-factory in jdoconfig.xsd

In terms of behavior, we could start with the obvious:

For datastore transactions, the isolation level cannot be changed while a transaction is in progress. 

For datastore transactions, the underlying connection will be obtained using the specified isolation level or a higher one if the requested level is not supported.

For optimistic transactions, the isolation level *can* be changed while a transaction is in progress, and the level is used for any connections obtained during subsequent operations. 

For optimistic transactions, the underlying connection will be obtained using the specified isolation level or a higher one if the requested level is not supported.

Now for some non-obvious behavior, that I think we could debate for some time (and might not need to be resolved for this spin of the spec):

Do we allow commits if there was ever any data obtained with the isolation level set to TX_READ_UNCOMMITTED, regardless of whether the data is part of the commit set?

In an optimistic transaction, do we automatically enlist any instances (implied makeTransactional) obtained while TX_REPEATABLE_READ or higher was set?

> 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.