Re: AW: Re[2]: [OJB-developers] Re: OJB-ODMG does[n't] support implic it locking

[Doug C. <de...@fl...>]

>> In two tests I used: <MappingRepository isolation="repeatable-read">

> Hmm, is this a typo? isolation must be declared per ClassDescriptor?

I thought this construction changed the default isolation for all
classes. I overlooked the fact that Article's isolation
level is set explicitly. (I was looking at test.ojb.broker.Article
instead of test.ojb.odmg.Article).

So, I ran the tests with the <MappingRepository isolation="repeatable-read">
but otherwise unmodifed repository using LockStrategyFactory.getStrategyFor()
to see the isolation level...

run_odmg_example:
    [junit] .[BOOT] INFO: OJB.properties: file:/D:/ejava/ojb-0.7.315/build/test/ojb/OJB.properties
    [junit] ....[ODMG] ERROR: !!! L: ojb.odmg.locking.RepeatableReadStrategy@406199
    [junit] [ODMG] ERROR: !!! L: not read locked!
    [junit] .[ODMG] ERROR: !!! L: ojb.odmg.locking.ReadUncommittedStrategy@61f24
    [junit] [ODMG] ERROR: !!! not read locked !!!
    [junit] [ODMG] ERROR: !!! dirty cache !!!

the RepeatableReadStrategy object is the result of a query on a named
DList (remember my ealier bug report). You are right, the Article is
ReadUncommittedStrategy. So I changed the Article class isolation...
    
run_odmg_example:
    [junit] .[BOOT] INFO: OJB.properties: file:/D:/ejava/ojb-0.7.315/build/test/ojb/OJB.properties
    [junit] ....[ODMG] ERROR: !!! L: ojb.odmg.locking.RepeatableReadStrategy@406199
    [junit] [ODMG] ERROR: !!! L: not read locked!
    [junit] .[ODMG] ERROR: !!! L: ojb.odmg.locking.RepeatableReadStrategy@406199
    [junit] [ODMG] ERROR: !!! dirty cache !!!

and now we do have a read lock after the query, but still have the
implicit write lock "bug." Er, feature.
    
<snip>

> As a consequence of our discussion I placed a note on the feature list and
> on the roadmap page stating that implicit locking is not fully implemented
> and that users must use explicit lock to have proper tx isolation.

Very good. That's all we really need.

> I assume we really need object clones per ODMG transaction to have a clean
> optimistic locking.
> Apropos: Jakob implemented locking and it is already integrated into the
> latest 0.7.325 release!

I meant to write about this. It looks very nice. It is everything we'd
need at the broker level for optimistic locking, but as you say, unless
we have multiple clones of objects (in the simplest case one per
transaction) it won't provide transaction isolation.

e