Hi Armin,
On Wed, 10 Nov 2004 14:30:58 +0100, Armin Waibel <[EMAIL PROTECTED]>
wrote:
>Hi Gerhard,
>
>indeed this code snip is strange and it is possible to write a test to
>reproduce your scenario.
>How should method #releaseLock behave? Always release all locks or only
>release the lock with highest priority (current behavior)?
#releaseLock is basically called from TransactionImpl when the
transaction, successfull or not, cleans up. I tend to think that all
locks, read and write, acquired by the transaction should be released
at this point.
We had a situation where a left-over read-lock was really disturbing
and we therefore patched the code in all LockStrategy implementations
(except ReadUncommittedStrategy, which does not use read-locks) to
always also release the read-locks. We have a pretty large test suite
for our application and no test case failed after the change.
Unfortunately I had not run OJB's own unit tests before. Running it
now produced 2 failures within the ODMG test:
Testcase: testRemoveCollectionElementWithoutBackReference took 0,015
sec
FAILED
Wrong number of objects found expected:<2> but was:<3>
junit.framework.AssertionFailedError: Wrong number of objects found
expected:<2> but was:<3>
at
org.apache.ojb.odmg.CollectionsTest.testRemoveCollectionElementWithoutBackReference(CollectionsTest.java:176)
Testcase: testStoreFetchDeleteCollectionWithBackReference took 0,016
sec
Testcase: testStoreDeleteCollectionElementWithBackReference took 0,031
sec
FAILED
expected:<2> but was:<3>
junit.framework.AssertionFailedError: expected:<2> but was:<3>
at
org.apache.ojb.odmg.CollectionsTest.testStoreDeleteCollectionElementWithBackReference(CollectionsTest.java:331)
I tend to believe that these failerures have nothing to do with
releasing read locks. We have a number of other modifications which
might cause this.
Thanks for your comment!
Gerhard
>
> > and then the method returns. If there are also read locks (and usually
> > there are!) they will remain active until the lock map cleans up those
> > 'forgotten' locks. Bug or feature?
>
>This part of OJB is really old (in OJB1.0.x we moved these classes into
>the kernel, but without real refactoring). To answer you question, I
>tend to bug.
>
>regards,
>Armin
>
>
>Gerhard Grosse wrote:
>
>> Hi,
>>
>> The following code is copied from
>> org.apache.ojb.odmg.locking.ReadCommittedStrategy:
>>
>> /**
>> * release a lock on Object obj for Transaction tx.
>> * @param tx the transaction releasing the lock
>> * @param obj the Object to be unlocked
>> * @return true if successful, else false
>> *
>> */
>> public boolean releaseLock(TransactionImpl tx, Object obj)
>> {
>> LockEntry writer = getWriter(obj);
>>
>> if (writer != null && writer.isOwnedBy(tx))
>> {
>> removeWriter(writer);
>> return true;
>> }
>>
>> if (hasReadLock(tx, obj))
>> {
>> removeReader(tx, obj);
>> return true;
>> }
>> return false;
>> }
>>
>>
>> Obviously, if there is a write-lock on an object, it will be removed
>> and then the method returns. If there are also read locks (and usually
>> there are!) they will remain active until the lock map cleans up those
>> 'forgotten' locks. Bug or feature?
>>
>> Gerhard
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
