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 10:00:23 GMT
Hi Andy,

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.

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 <andy@jpox.org>
To:
jdo-dev@db.apache.org
Cc:
JDO Expert Group <jdo-experts-ext@sun.com>
Date:
17.03.2008 10:21
Subject:
Re: JDO 2.2 : transaction isolation



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)


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