#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.
agree!
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.
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?
...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.
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]
