db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CRomb...@versant.com
Subject Re: JDO 2.2 : transaction isolation
Date Mon, 17 Mar 2008 08:42:40 GMT
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 
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 

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,


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.

Andy Jefferson <andy@jpox.org>
jdo-dev@db.apache.org, JDO Expert Group <jdo-experts-ext@sun.com>
16.03.2008 15:22
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 
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)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message