Hi Andy, these levels are not really appropriate for JDO, which is because of the nature these are defined in the SQL spec:
Lets consider two cases: 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". 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. Best regards, Christian --- Versant GmbH European Headquarters Christian Romberg Wiesenkamp 22 b D 22359 Hamburg --- Versant GmbH is incorporated in Germany. Company registration number: HRB 54723, Amtsgericht Hamburg. Registered Office: Wiesenkamp 22b, 22359 Hamburg, Germany. Geschäftsführer: Jochen Witte. From: Andy Jefferson <[EMAIL PROTECTED]> To: [email protected], JDO Expert Group <[EMAIL PROTECTED]> Date: 16.03.2008 15:22 Subject: JDO 2.2 : transaction isolation This has probably been mentioned by others but I'll request it for JDO2.2 since it has certainly been requested enough amongst users groups. We should take the javax.jdo.Transaction interface and add the following public static final int TRANSACTION_NONE = 0; public static final int TRANSACTION_READ_UNCOMMITTED = 1; public static final int TRANSACTION_READ_COMMITTED = 2; public static final int TRANSACTION_REPEATABLE_READ = 4; public static final int TRANSACTION_SERIALIZABLE = 8; public void setIsolationLevel(int isolation); public int getIsolationLevel(); Definitions of the 5 levels would be broadly as per the java.sql.Connection class. Support for particular levels would always depend on whether the underlying datastore supports that level - not all RDBMS or ODBMS support all. Maybe define setIsolationLevel() to throw a JDOException if the underlying datastore doesn't support that level. Comments ? -- Andy (Java Persistent Objects - http://www.jpox.org)
