----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://review.cloudera.org/r/691/#review966 -----------------------------------------------------------
/trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java <http://review.cloudera.org/r/691/#comment3144> oh wow i cant believe this was ever here /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java <http://review.cloudera.org/r/691/#comment3145> i thought we agreed that the closing flag had to be set BEFORE the write lock was acquired to prevent race conditions? /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java <http://review.cloudera.org/r/691/#comment3146> lets just excise this and break compile time compatibility. Also remove internalPreFlushcacheCommit too /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java <http://review.cloudera.org/r/691/#comment3147> ditto remove this whole try/finally bit /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java <http://review.cloudera.org/r/691/#comment3148> maybe we shouldnt call this 'transaction' might confuse people into thinking we support real transactions... not sure what to call it at this moment tho - Ryan On 2010-08-19 14:59:41, Jean-Daniel Cryans wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://review.cloudera.org/r/691/ > ----------------------------------------------------------- > > (Updated 2010-08-19 14:59:41) > > > Review request for hbase. > > > Summary > ------- > > This patch removes newScannerLock and renames splitAndClose lock to just > "lock". Every operation is now required to obtain the read lock on "lock" > before doing anything (including getting a row lock). This is done by calling > openRegionTransaction inside a try statement and by calling > closeRegionTransaction in finally. > > flushcache got refactored some more in order to do the locking in the proper > order; first get the read lock, then do the writestate handling. > > Finally, it removes the need to have a writeLock when flushing when > subclassers give atomic work do to via internalPreFlushcacheCommit. This > means that this patch breaks external contribs. This is required to keep our > whole locking mechanism simpler. > > > This addresses bug HBASE-2915. > http://issues.apache.org/jira/browse/HBASE-2915 > > > Diffs > ----- > > /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java > 987300 > > /trunk/src/main/java/org/apache/hadoop/hbase/regionserver/SplitTransaction.java > 987300 > > /trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransaction.java > 987300 > > Diff: http://review.cloudera.org/r/691/diff > > > Testing > ------- > > 5 concurrent ICV threads + randomWrite 3 + scans on a single RS. I'm also in > the process of deploying it on a cluster. > > > Thanks, > > Jean-Daniel > >
