Hi Christian, Thx for your input.
> these levels are not really appropriate for JDO, which is because of the > nature these are defined in the SQL spec: > I. with a database guarantee of only committed reads and using JDO > optimistic transactions, you effectively have an isolation level stronger > than TRANSACTION_READ_COMMITTED and lower than > TRANSACTION_REPEATABLE_READ because the phenomenon of "unrepeatable reads" > can occur, while the phenomenon of "lost updates" can not occur. > In our (old) implementation we thus introduced an additional isolation > level "NO_LOST_UPDATES". Ok. > II. with a database guarantee of serializibility and using JDO optimistic > transactions, you don't achieve > serializable JDO transactions unless the physical connection is bound to > the PM for the whole JDO transaction duration. Agreed. There are 2 sides to this :- 1). Standardising a mechanism for specifying the transaction isolation level. This is what 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 you say, that 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. Is this realistic? 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. Regards -- Andy (Java Persistent Objects - http://www.jpox.org)
