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)?
> 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]
