You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Gerhard Grosse <ge...@lex-com.net> on 2004/11/09 17:56:06 UTC
Read locks not released in ReadCommittedStrategy
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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Read locks not released in ReadCommittedStrategy
Posted by Gerhard Grosse <ge...@lex-com.net>.
On Wed, 10 Nov 2004 16:14:36 +0100, Armin Waibel <ar...@apache.org>
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: ojb-user-unsubscribe@db.apache.org
>>>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Read locks not released in ReadCommittedStrategy
Posted by Armin Waibel <ar...@apache.org>.
Gerhard Grosse wrote:
> #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: ojb-user-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Read locks not released in ReadCommittedStrategy
Posted by Gerhard Grosse <ge...@lex-com.net>.
Hi Armin,
On Wed, 10 Nov 2004 14:30:58 +0100, Armin Waibel <ar...@apache.org>
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: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Read locks not released in ReadCommittedStrategy
Posted by Armin Waibel <ar...@apache.org>.
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: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org