commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <oliver.zeigerm...@gmail.com>
Subject Re: [transaction.locking] Modify the behaviour of the ReadWriteUpgradeLockManager
Date Thu, 31 Mar 2005 19:56:47 GMT
Hmmm, not quite sure that I get this all right, but to me it seems you
describe the simple read/write locks (without the upgrade step). Is
that possible? If so you could simply use the ReadWriteLockManager.

Oliver


On Thu, 31 Mar 2005 14:34:24 +0200, Melanie.Bats@UTBM.fr
<Melanie.Bats@utbm.fr> wrote:
> Hi,
> 
> In the documentation I find that while an upgrade lock is held, it is possible
> for read locks to be obtained, and when the request is made to upgrade to a
> write lock, the lock manager prevents additional read locks until the write lock
> can be acquired.
> 
> I don't understand why when the upgrade lock is granted, it is possible to
> obtain read locks ? Is there a reason to keep accepting read locks when you
> already know (because there is a upgrade lock on the data) that the data will be
> updated soon ?
> 
> The behaviour that I want for my lock manager is following. To modify a data,
> you must obtain an upgrade lock if there is already read locks on the data and
> then to transform the upgrade lock in write lock when all the readers ended.
> When the upgrade lock is granted no more read locks could be granted.
> 
> Is it possible to implements this behaviour using the
> ReadWriteUpgradeLockManager ?
> 
> For the moment I implements the transformation of an upgrade lock in a write
> lock when all readers finished.
> 
> public class LockManager
> {
>    public static ReadWriteUpgradeLockManager mRWULockManager;
> 
>   public LockManager()
>   {
>      mRWULockManager = new ReadWriteUpgradeLockManager
>         (new PrintWriterLogger(new PrintWriter(System.out), "Locking", false)
>          , mRWULockManager.DEFAULT_TIMEOUT);
>   }
> 
>   public static void readDemand(Thread aOwnerId, Interval1D aIntervalToLock)
>   {
>      mRWULockManager.readLock(aOwnerId, aIntervalToLock);
>   }
> 
>   public static  void writeDemand(Thread aOwnerId, Interval1D aIntervalToLock)
>   {
>     if(mRWULockManager.tryWriteLock(aOwnerId, aIntervalToLock) == false)
>     {
>       upgradeDemand(aIntervalToLock, aOwnerId);
>       synchronized(aIntervalToLock)
>       {
>         try
> 
>           aIntervalToLock.wait();
>           writeDemand(aOwnerId, aIntervalToLock);
>       }
>         catch (Exception e) {}
>       }
>     }
>   }
> 
>   /**
>    * Traitement d'une demande d'un lock Upgrade
>    * @param aOwnerId Thread Identifiant du demandeur
>    * @param aIntervalToLock Interval1D Intervalle à verrouiller
>    */
>   public static void upgradeDemand(Interval1D aIntervalToLock, Thread aOwnerId)
>   {
>     if(PDOM.TRACE)
>       System.out.println("LM: Upgrade Demand");
>     mRWULockManager.tryUpgradeLock(aOwnerId, aIntervalToLock);
>   }
> 
>   /**
>    * Relacher un lock
>    * @param aIntervalToUnlock Interval1D
>    * @param aOwnerId Thread
>    */
>   public static void release(Interval1D aIntervalToUnlock, Thread aOwnerId)
>   {
>     if(PDOM.TRACE)
>       System.out.println("LM: Release " + aOwnerId + " " + aIntervalToUnlock);
>     synchronized(aIntervalToUnlock)
>     {
>       mRWULockManager.release(aOwnerId, aIntervalToUnlock);
>       aIntervalToUnlock.notifyAll();
>       if(PDOM.TRACE)
>         System.out.println("LM: ******** Il devrait repartir ********");
>     }
>   }
> 
> In this sense the write lock becomes preferred over all other locks when it gets
> upgraded from a upgrade lock. Preferred means that if it has to wait and others
> wait as well it will be served before all other none preferred locking requests.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message