db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Richman <j...@shift9.com>
Subject Re: odmg locking questions
Date Tue, 08 Jul 2003 01:49:17 GMT
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


Mime
View raw message