db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christiaan <christiaan...@hotmail.com>
Subject Re: JDO 2.2 : transaction isolation
Date Tue, 18 Mar 2008 11:53:10 GMT

Hi,

CRomberg wrote:
> 
> we have to distinguish optimistic and datastore transactions in this 
> discussion, and also
> what we want to achieve.
> 

You probably also need to include a description of the behaviour when
non-transactional read / write properties are used? 


CRomberg wrote:
> 
> 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. 
> 

Shouldn't the check be peformed when reading values as well? i.e. once a
value is read, a subsequent read should read the same value, even if evict()
is called?

I think it would at least be a good idea to have some more clarification in
the spec of what is possible and what is not possible and what makes sense
or not. 


CRomberg wrote:
> 
> 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 
> 

I agree. We use READ_UNCOMMITTED in order to have better performance. This
made sense since we implemented locking on a more conceptual level, not rows
or tables, but aggregates of objects. 
Regarding the NO_LOST_UPDATES, I am not sure whether I understand that with
READ_COMMITTED this cannot occur as you say? I think it would also be nice
that you can include a strategy how to handle lost updates, eg. "last update
wins", "first read wins" or "first update wins"

kind regards,
Christiaan
-- 
View this message in context: http://www.nabble.com/JDO-2.2-%3A-transaction-isolation-tp16079493p16119531.html
Sent from the JDO - Development mailing list archive at Nabble.com.


Mime
View raw message