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

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.

     [ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Craig Russell updated JDO-590:
------------------------------

    Component/s: tck2-legacy
                 tck2
                 specification
                 api2-legacy

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

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

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

My requirements for this item are to provide a *mechanism* for specification of transaction isolation. That is point 1 in the issue above. In the absence of interest in doing the second part I suggest that this is what we do here. Either way, if we do or not the second part we need a way of specifying transaction isolation.

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

So we allow a text string form of isolation level. This then encompasses some standardised values and also allows implementations to define their own particular extensions to cater for the problems Christian Romberg mentioned. We could easily provide the following statics on javax.jdo.Transaction
"TX_NONE", TX_READ_UNCOMMITTED", "TX_READ_COMMITTED", "TX_NO_LOST_UPDATES", "TX_REPEATABLE_READ", "TX_SERIALIZABLE"

Specification of this parameter would mean that the datastore would use that isolation *if it is supported by the datastore*. Some datastores don't support any transaction capabilities. Some could be mimicked by the JDO layer. The only part here that would be desirable to have is an additional method
String[] getSupportedTransactionIsolations();
to return what the datastore supports. This should go on javax.jdo.Transaction


If there are people who want the second part of this issue then they really ought to put forward their time to flush out what issues they see with it; as I said I have no desire for that part.

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

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

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

The structure of this proposal makes sense: add get/set TransactionIsolation to Transaction and PersistenceManagerFactory; and add a property (and xml attribute to jdoconfig).

The values for the Strings might be context sensitive, so need a bit of thought. In an xml file, "read-committed" is probably a good value to use, and TX_READ_COMMITTED is a good name for the public final String variable (in javax.jdo.Constants).

I've read (again) this excellent and uncontroverted paper on isolation levels, and I'd recommend it for others: http://www.cs.umb.edu/~poneil/iso.pdf

I'm not convinced of the need for TX_NONE, as I'm not sure what it means.

I'm not sure that we should mix isolation level names with phenomena, so TX_NO_LOST_UPDATES might not be needed.

It might be useful to introduce TX_SNAPSHOT and TX_CURSOR_STABILITY into the mix to accommodate non-ANSI-SQL datastores. These would also allow users to request specific handling of some long-running cursored queries and the use of mvcc if available on the datastore.

Issues:

1. We do need to be clear what the application guarantees are if they choose to use specific transaction isolation settings. We could do what the ANSI and JDBC standards require: that if the user asks for an isolation that the underlying datastore doesn't support, the request is "upgraded" to a setting that is supported. This would accommodate users asking for SNAPSHOT on datastores that don't support it by mapping it to SERIALIZABLE.

2. We need to think about how to use the isolation setting with Optimistic transactions. Does it even make sense? The idea of optimistic is that a non-transactional connection is used for all operations before flush. So with optimistic transactions, does the isolation level apply only to the final (transactional) connection?

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