On Wed, 10 Nov 2004 16:14:36 +0100, Armin Waibel <[EMAIL PROTECTED]>
wrote:
>
>ok, will patch the LockStrategy classes to release the read-locks too.
>Additionally I will try to make some modifications for better
>performance, e.g. in your code snip is done
>
> >> if (hasReadLock(tx, obj))
> >> {
> >> removeReader(tx, obj);
> >> return true;
> >> }
> >> return false;
>
>assume we have a distributed LockMap this call isn't smart, a better one
>could be
>
>return removeReader(tx, obj);
>
>and method #removeReader returns 'true' when a reader was successfully
>removed.
>
>Is it possible for you to run the OJB 1.0.x branch against your large
>test suite (after check in of the changes) to make possible that the
>changes made to odmg implementation doesn't break previous releases?
>
In principle, yes. It will take a couple days, though, because I have
to find a good way to merge OJB's changes since 1.0.1 with our
modifications, which is something we need to do anyway at some point.
We have our modifications under our own CVS, but unfortunately I did
not put them in a branch. So I have to think a little...
>
>> Unfortunately I had not run OJB's own unit tests before. Running it
>> now produced 2 failures within the ODMG test:
>...
>> 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.
>>
>
>Don't worry! These two failures are new tests showing open issues, they
>fail in the 1.0.x branch/trunk too.
>
Good to know. Thanks!
Gerhard
>
>regards,
>Armin
>
>
>> 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]
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
