hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dhruba Borthakur <dhr...@gmail.com>
Subject locking hierarchy in HBase
Date Fri, 05 Mar 2010 08:40:54 GMT
I am  trying to come up with a locking hierarchy document for all the locks
used in HBase.  Any details/feedback anybody can share to make this document
better
would be much appreciated. This heirarchy can be used to interpreted as: a
thread that has a lock C cannot acquire A or B, and so on.

A. HRegionServer.lock
  This lock protects the list of regions maintained by a region server.
  The lock protects a data structure called onlineRegions that mantains a
  map of region names to HRegion.
  Question:  what is region quiesce?

B. HRegion.newScannerLock
   This lock ensures that puts and deletes are atomic. Also, one cannot
close
   a region unless all puts, deletes and scans are completed.
              put gets a writelock
              delete gets a writelock
              scanner gets a readlock
              regionclose gets a writelock
              flushcache gets a writelock to switch between memstore
                         and new store files

C. HRegion.splitsAndClosesLock
   This lock ensures that compactions and flshCaches are completed before
   a region close is successful. I do not yet understand why put and delete
   have to acquire this lock.
              put gets a readlock to check if record already exists
              delete gets a readlock
              compaction gets a readlock
              flushCache gets a readlock
              regionclose gets a writelock

D. RowLock
   This is for atomic updates of a row.
              put gets a rowlock

E. HRegion.updatesLock
              put gets a readlock to insert entire key into memstore and
hlog
              delete gets a readlock
              interalFlushCache gets a writelock to snapshot memstore and
hlog

F. HRegion.synchronized_splitLock
G. HRegion.synchronized_writestate

H. MemStore.lock

I. Store.compactLock
             compaction gets a writelock: allows only 1 compaction at a time
J. Store.lock
              add(KeyValue) gets a readlock
              delete(KeyValue) gets a readlock
              get(KeyValue) gets a readlock
              close gets a writelock
              completeCompaction gets a writelock

---------------------------------------------
One posible problem lock hierarchy violation:
HRegion.flushcache holds the splitsAndClosesLock.readlock and then invokes
internalFlushCache. internalFlushCache  acquires the netScannerLock to
switch
between memstore and new store files. could this cause a problem?


-- 
Connect to me at http://www.facebook.com/dhruba

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message