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.
