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 "Andy Jefferson (JIRA)" <ji...@apache.org> on 2008/04/11 15:42:06 UTC
[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.
[jira] Updated: (JDO-590) Control over transaction isolation level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-590:
------------------------------
Attachment: (was: jdo-590.patch)
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630908#action_12630908 ]
Andy Jefferson commented on JDO-590:
------------------------------------
DataNucleus SVN for version 1.0 and version 1.1 (and nightly build) should now pass all txn isolation tests except the "PMF by API" test (tested on 1.1, but changes applied to 1.0 also so should work).
PS. The SetXXX tests need adding to pmf.conf, transaction.conf
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630901#action_12630901 ]
Craig Russell commented on JDO-590:
-----------------------------------
> A slight flaw with my previous suggestion of throwing an exception at PMF creation when the isolation level is unsupported. When the PMF is created the configuration is not frozen until the first PM is requested. Consequently the connection to the datastore is not established until that point, and so it doesn't know what transaction isolation levels are supported until then.
This is only an issue when configuring the PMF by API. If it's configured by properties, then the configuration is frozen and the exception can be thrown then.
If configuring the PMF by API, the exception can be thrown upon the first getPM request (when the configuration is frozen), instead of when the setTransactionIsolationLevel method is called. Not ideal but maybe better than not allowing configuration of the PMF with a default 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, 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629937#action_12629937 ]
Craig Russell commented on JDO-590:
-----------------------------------
One more note as I was working on the test cases.
I'd like to require that an implementation support at least javax.jdo.option.TransactionIsolationLevel.read-committed.
If a datastore doesn't support read-committed isolation level I honestly don't know how it could pass the TCK (or be generally useful).
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629348#action_12629348 ]
Craig Russell commented on JDO-590:
-----------------------------------
Coming back to the constants, should we have the full name of the property available as a constant? e.g.
static String PROPERTY_TRANSACTION_ISOLATION_LEVEL
= "javax.jdo.option.TransactionIsolationLevel";
but also five more specific property names, e.g.
static String PROPERTY_TRANSACTION_ISOLATION_LEVEL_READ_COMMITTED
= "javax.jdo.option.TransactionIsolationLevel.read-committed";
This would avoid the user having to construct the property name from PROPERTY_TRANSACTION_ISOLATION_LEVEL + "." + TX_READ_COMMITTED
> 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.
[jira] Updated: (JDO-590) Control over transaction isolation level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629149#action_12629149 ]
Andy Jefferson commented on JDO-590:
------------------------------------
I'd change my original comment of method names etc. We have "isolationLevel" on Transaction and "transactionIsolation" on PMF. Maybe ought to be consistent, so change the PMF ones to be
void setTransactionIsolationLevel(String);
String getTransactionIsolationLevel();
javax.jdo.option.TransactionIsolationLevel
Agree with all of obvious behaviour wrt ability to change isolation. What is "higher" in the sense of a level? Serializable = highest ? What if the user requests an isolation level and the datastore doesn't support that, and there isn't a "higher" one ... choose the "highest" supported 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, 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.
[jira] Updated: (JDO-590) Control over transaction isolation level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-590:
------------------------------
Attachment: jdo-590.patch
I've changed Transaction.setTransactionIsolationLevel to Transaction.setIsolationLevel.
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630788#action_12630788 ]
Craig Russell commented on JDO-590:
-----------------------------------
Good catches on the javadoc.
A minor spec update. I'd like to improve
A13.4.2-25 [For datastore transactions, the isolation level cannot be changed while a transaction is in progress.]
to
A13.4.2-25 [For datastore transactions, the isolation level cannot be changed while a transaction is in progress. Calling setIsolationLevel while a datastore transaction is in progress throws JDOUserException.]
The implementation can change the isolation level requested to a higher level without throwing an exception. What should the result of the getIsolationLevel call be? The requested level or the higher level? I have mixed thoughts, but at the end, I think it should return the actual isolation level that is being used by the implementation.
And the specification doesn't name the standard isolation levels. I'll add them to the draft spec text.
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629333#action_12629333 ]
Craig Russell commented on JDO-590:
-----------------------------------
> javax.jdo.option.TransactionIsolationLevel.TX_READ_COMMITTED
> javax.jdo.option.TransactionIsolationLevel.TX_READ_UNCOMMITTED
> javax.jdo.option.TransactionIsolationLevel.TX_REPEATABLE_READ
> javax.jdo.option.TransactionIsolationLevel.TX_SNAPSHOT
> javax.jdo.option.TransactionIsolationLevel.TX_SERIALIZABLE
should be
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
I was confusing variable names with values...
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630854#action_12630854 ]
Andy Jefferson commented on JDO-590:
------------------------------------
A slight flaw with my previous suggestion of throwing an exception at PMF creation when the isolation level is unsupported. When the PMF is created the configuration is not frozen until the first PM is requested. Consequently the connection to the datastore is not established until that point, and so it doesn't know what transaction isolation levels are supported until then.
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629234#action_12629234 ]
Craig Russell commented on JDO-590:
-----------------------------------
> Maybe ought to be consistent, so change the PMF ones to be
> void setTransactionIsolationLevel(String);
And I thought I was the only one who liked long names ;-) I have no objection to rationalizing names using the longer proposed name.
> Agree with all of obvious behaviour wrt ability to change isolation. What is "higher" in the sense of a level? Serializable = highest ?
Yes, I ordered the TX_ constants in order from lowest (TX_READ_UNCOMMITTED) to highest (TX_SERIALIZABLE).
> What if the user requests an isolation level and the datastore doesn't support that, and there isn't a "higher" one ... choose the "highest" supported level?
I think throwing an exception is probably the right thing to do. Portable applications just shouldn't get bizarre behavior if the isolation level they want isn't available. Put another way, wouldn't the application developer be better off knowing that the application won't run correctly?
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630839#action_12630839 ]
Craig Russell commented on JDO-590:
-----------------------------------
svn commit -m "JDO-590 Prepare JDO_Test for isolation level" trunk/api2/src/java/javax/jdo/Constants.java trunk/tck2/src/java/org/apache/jdo/tck/JDO_Test.java trunk/tck2/src/java/org/apache/jdo/tck/query/jdoql/ComparingCollectionFieldToNull.java
Sending trunk/api2/src/java/javax/jdo/Constants.java
Sending trunk/tck2/src/java/org/apache/jdo/tck/JDO_Test.java
Sending trunk/tck2/src/java/org/apache/jdo/tck/query/jdoql/ComparingCollectionFieldToNull.java
Transmitting file data ...
Committed revision 695064.
svn commit trunk/tck2/src/conf/jdo-2_2-signatures.txt trunk/tck2/src/java/org/apache/jdo/tck/api/persistencemanagerfactory/SetTransactionIsolationLevel.java trunk/tck2/src/java/org/apache/jdo/tck/transactions/SetIsolationLevel.java trunk/api2/src/java/javax/jdo/PersistenceManagerFactory.java trunk/api2/src/java/javax/jdo/Transaction.java trunk/api2/src/schema/javax/jdo/jdoconfig_2_2.dtd trunk/api2/src/schema/javax/jdo/jdoconfig_2_2.xsd
Sending trunk/api2/src/java/javax/jdo/PersistenceManagerFactory.java
Sending trunk/api2/src/java/javax/jdo/Transaction.java
Sending trunk/api2/src/schema/javax/jdo/jdoconfig_2_2.dtd
Sending trunk/api2/src/schema/javax/jdo/jdoconfig_2_2.xsd
Sending trunk/tck2/src/conf/jdo-2_2-signatures.txt
Adding trunk/tck2/src/java/org/apache/jdo/tck/api/persistencemanagerfactory/SetTransactionIsolationLevel.java
Adding trunk/tck2/src/java/org/apache/jdo/tck/transactions/SetIsolationLevel.java
Transmitting file data .......
Committed revision 695066.
Add get/set isolation methods to Transaction and PersistenceManagerFactory
New test cases for Transaction and PersistenceManagerFactory isolation level
New jdoconfig attributes for isolation level
Updated signatures for new methods
The tck tests fail due to unexpected exception types thrown: IllegalArgumentException instead of the expected JDOUnsupportedOptionException, per spec
A11.1-38 [Any standard property corresponding to an optional feature not supported by the implementation must throw JDOUnsupportedOptionException.]
A13.4.2-5, A13.4.2-6, A13.4.2-7, A13.4.2-8, A13.4.2-20[If an implementation does not support the option, then an attempt to set the flag to an unsupported value will throw JDOUnsupportedOptionException.]
Another test fails because an attempt is made to set the isolation level when a datastore transaction is active.
As always, please review and comment.
> 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.
[jira] Updated: (JDO-590) Control over transaction isolation level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-590:
------------------------------
Attachment: jdo-590.patch
Updated patch with tck2 tests for both PersistenceManagerFactory and Transaction.
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629287#action_12629287 ]
Craig Russell commented on JDO-590:
-----------------------------------
> String[] Transaction.getSupportedIsolationLevels();
We already have
Collection<String> supportedOptions();
Would it make sense to add the supported TX options here? e.g. for datastores that don't support TX_READ_UNCOMMITTED
...
javax.jdo.option.TransactionIsolationLevel.TX_READ_COMMITTED
javax.jdo.option.TransactionIsolationLevel.TX_REPEATABLE_READ
javax.jdo.option.TransactionIsolationLevel.TX_SNAPSHOT
javax.jdo.option.TransactionIsolationLevel.TX_SERIALIZABLE
An application could do the usual supportedOptions().contains("javax.jdo.option.TransactionIsolationLevel.TX_REPEATABLE_READ") to find out if repeatable read (or higher) was supported.
> 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.
[jira] Updated: (JDO-590) Control over transaction isolation level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-590:
------------------------------
Attachment: (was: jdo-590.patch)
> 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.
[jira] Resolved: (JDO-590) Control over transaction isolation level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell resolved JDO-590.
-------------------------------
Resolution: Fixed
The specification dated October 3 has the changes.
> 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-pmf_by_api.patch, 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633845#action_12633845 ]
Andy Jefferson commented on JDO-590:
------------------------------------
Applied changes for API to api2-legacy. Without this anyone using DataNucleus would be unable to do anything when using JDK1.3/1.4. No plans to apply the TCK changes across to tck2-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
> Assignee: Craig Russell
> Fix For: JDO 2 maintenance release 2
>
> Attachments: jdo-590-pmf_by_api.patch, 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.
[jira] Updated: (JDO-590) Control over transaction isolation level
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Jefferson updated JDO-590:
-------------------------------
Attachment: jdo-590-pmf_by_api.patch
Patch to setTransactionIsolationLevelByAPI so that we create the first PM and check on exceptions being thrown at that point. If an exception is thrown then checks if the level is supported (since the supported isolation levels likely aren't known til freezing the PMF). If no exception is thrown then checks that the level is unsupported (and so shouldn't have returned the PM).
> 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-pmf_by_api.patch, 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Andy Jefferson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629762#action_12629762 ]
Andy Jefferson commented on JDO-590:
------------------------------------
DataNucleus now has the required methods implemented in datanucleus-core-1.0-SNAPSHOT.jar and datanucleus-core-1.1-SNAPSHOT.jar.
The only problem I have is that the patch has
Transaction.setTransactionIsolationLevel()
Transaction.getTransactionIsolationLevel()
PMF.setTransactionIsolationLevel()
PMF.getTransactionIsolationLevel()
yet I thought we were going to have
Transaction.setIsolationLevel
Transaction.getIsolationLevel
PMF.setTransactionIsolationLevel()
PMF.getTransactionIsolationLevel()
so only have the long name on the PMF (since the methods on Transaction we know are about transaction).
> 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.
[jira] Updated: (JDO-590) Control over transaction isolation level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated JDO-590:
------------------------------
Attachment: jdo-590.patch
Please review this patch.
The runonce.conf tck test passes...
> 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.
[jira] Commented: (JDO-590) Control over transaction isolation
level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JDO-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634962#action_12634962 ]
Craig Russell commented on JDO-590:
-----------------------------------
Just one comment on the tck patch. The line
+ pmf.setConnectionDriverName(getPMFProperty("javax.jdo.option.ConnectionDriverName"));
could use the Constants string for the property
+ pmf.setConnectionDriverName(getPMFProperty(PROPERTY_CONNECTION_DRIVER_NAME));
With this change, it's good to commit.
And the new behavior needs to be documented in the specification, which I will take care of.
> 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-pmf_by_api.patch, 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.
[jira] Assigned: (JDO-590) Control over transaction isolation level
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ 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.