db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: odmg locking questions
Date Tue, 08 Jul 2003 06:11:46 GMT
Oops,

yes you are right! this seems to be a bug.
Maybe Matthew knows more about this issue?

cheers,
Thomas


Steven Richman wrote:
> Yes, I saw that. I don't see how this prevents two threads from getting 
> the write lock at the same time:
> 
>         /**
>          * MBAIRD: We need to synchronize the get/put so we don't have two 
> threads
>          * competing to check if something is locked and double-locking 
> it.
>          */
> 		synchronized (locktable)
> 		{
> 	        objectLocks = (ObjectLocks) locktable.get(oid.toString());
> 	        if (objectLocks == null)
> 	        {
> 	            objectLocks = new ObjectLocks();
> 	            locktable.put(oid.toString(), objectLocks);
> 	        }
> 		}
>         objectLocks.setWriter(writer);
>         return true;
> 
> So, if another thread has the lock, locktable.get will return the existing
> ObjectLocks object, objectLocks.setWriter will happily overwrite the
> writer member variable, and InMemoryLockMapImpl.setWriter will return
> true.
> 
> ,steven.
> 
> On Mon, 7 Jul 2003, Thomas Mahler wrote:
> 
> 
>>We are relying on Java synchronisation in setWriter:
>>         /**
>>          * MBAIRD: We need to synchronize the get/put so we don't have 
>>two threads
>>          * competing to check if something is locked and double-locking it.
>>          */
>>		synchronized (locktable)
>>...
>>
>>
>>
>>Steven Richman wrote:
>>
>>>Hi,
>>>
>>>I'm trying to understand some of the code in the odmg locking 
>>>implementation.
>>>
>>>In all of the locking strategies, there is code like this:
>>>
>>>    public boolean writeLock(TransactionImpl tx, Object obj)
>>>    {
>>>        LockEntry writer = getWriter(obj);
>>>        if (writer == null)
>>>        {
>>>            if (setWriter(tx, obj))
>>>                return true;
>>>            else
>>>                return writeLock(tx, obj);
>>>        }
>>>         ...
>>>
>>>(and similar code for read locks). Here, setWriter is
>>>AbstractLockStrategy.setWriter, which returns LockMap.setWriter. I'm using
>>>the InMemoryLockMapImpl, and if you look at the code for
>>>InMemoryLockMapImpl, setWriter *always* returns true.
>>>
>>>So, my question is, if the "if (writer == null)" test succeeds, but
>>>another thread acquires the lock before we call setWriter, isn't that bad?  
>>>setWriter always returns true, so the call to writeLock will return true,
>>>and there will be two threads that think they have the lock at the same
>>>time. Or is there some higher level synchronization that I'm missing that
>>>keeps this from happening?
>>>
>>>thanks,
>>>steven.
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message