Re: [OJB-developers] implicit locking and ODMG compliance (and JDO)

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

>> BTW, I am not advocating changing ojb to correct this problem, but
>> implicit locking should not be communicated to users as a feature,
>> and claims about compliance should be made with caveats.
>
>some of this does sound like OJB needs to be modified, doesn't it?

Well, if you want ODMG compliance, yes. We might also consider read
locking the results of queries. But the hair required to fix this
completely is so enormous that I think it would completely change the
nature of ojb. I am content with explicitly locking objects before
accessing or modifying them.

>>  /*5*/ transaction 2 aborts. This is irrelevant.
>>
>
>does not look that irrelevant to me. Modifications done in transaction 2
>should be rolled back in the instance as well, and thus not be visible
>afterwards.

These modifications would be rolled back if transaction 2 had obtained
a write lock. At least I believe that's the design, I haven't tested
it. So the bug is not getting the write lock.

>Visibility while the transaction is still active should depend
>on the isolation level of the other transaction (i.e., UNCOMMITTED READ
>should see it, COMMITTED READ shouldn't).

Yes. I tested it both ways: same result.

>>  JDO does require implicit locking, and uses a class "enhancer" to make
>>  it work. The reference implementation produces replacement java source
>>  code for peristent classes, and so does not completely implement the
>>  specification.
>
>to my knowledge, JDO does not mandate the use of the enhancer - so
>replacement code should be inside the spec as well. The enhancement issue
>was (and is) the subject of much debate (e.g., on TheServerSide), as you
>probably know. But of course, in order to meet the implicit locking
>requirement, there are not too many options...

... and they are all ugly.

e