commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Melanie.Bats@UTBM.fr" <Melanie.B...@utbm.fr>
Subject [transaction.locking] Modify the behaviour of the ReadWriteUpgradeLockManager
Date Thu, 31 Mar 2005 12:34:24 GMT
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


Mime
View raw message