To avoid the row lock deadlock case Ryan mentioned I created a patch to add
a non-blocking tryLock method to HTable. There's a patch at
https://issues.apache.org/jira/browse/HBASE-2584 although I'm not sure if it
still applies to trunk. The basic idea is to immediately return null if the
lock is
Date: Fri, 16 Jul 2010 13:02:15 -0700
Subject: Re: Row level locking?
From: ryano...@gmail.com
To: user@hbase.apache.org
CC: hbase-u...@hadoop.apache.org
HTable.close does very little:
public void close() throws IOException{
flushCommits();
}
None of which involves row
Currently a row is part of a region and there's a single region server serving
that region at a particular moment.
So when that row is updated a lock is acquired for that row until the actual
data is updated in memory (note that a put will be written to cache on the
region server and also
unless we know
that we're going to be writing a lot of data in the m/r job.
Thx
-Mike
From: cleh...@adobe.com
To: user@hbase.apache.org
CC: hbase-u...@hadoop.apache.org
Date: Fri, 16 Jul 2010 12:34:36 +0100
Subject: Re: Row level locking?
Currently a row is part of a region and there's
, 16 Jul 2010 12:34:36 +0100
Subject: Re: Row level locking?
Currently a row is part of a region and there's a single region server
serving that region at a particular moment.
So when that row is updated a lock is acquired for that row until the actual
data is updated in memory (note
...@hadoop.apache.org
Date: Fri, 16 Jul 2010 12:34:36 +0100
Subject: Re: Row level locking?
Currently a row is part of a region and there's a single region server
serving that region at a particular moment.
So when that row is updated a lock is acquired for that row until the
actual data
To: user@hbase.apache.orgmailto:user@hbase.apache.org
CC: hbase-u...@hadoop.apache.orgmailto:hbase-u...@hadoop.apache.org
Date: Fri, 16 Jul 2010 12:34:36 +0100
Subject: Re: Row level locking?
Currently a row is part of a region and there's a single region server
serving that region
Date: Fri, 16 Jul 2010 12:34:36 +0100
Subject: Re: Row level locking?
Currently a row is part of a region and there's a single region server
serving that region at a particular moment.
So when that row is updated a lock is acquired for that row until the
actual data is updated
On Fri, Jul 16, 2010 at 2:01 PM, Guilherme Germoglio
germog...@gmail.com wrote:
Just another question -- slightly related to locks. Will HBase 0.90
include HTable.checkAndPut receiving more than one value to check? I'm
eager to help, if possible.
I don't think there is even an issue to add
In the uncontended case this is fine, although you are doing 4 RPCs to
accomplish what could be done in 1 (with CAS).
But in the contended case, all the people waiting on that lock consume
RPC handler threads eventually causing a temporary deadlock since the
original lockholder will not be able
In that case it would be 2 RPC, right? do { get, update, checkAndPut }
while (ret = false)? Plus 2 for each contention?
Thanks,
-justin
On 7/16/10 5:09 PM, Ryan Rawson wrote:
In the uncontended case this is fine, although you are doing 4 RPCs to
accomplish what could be done in 1 (with
.
Cosmin
Thx
-Mike
From: cleh...@adobe.commailto:cleh...@adobe.com
To: user@hbase.apache.orgmailto:user@hbase.apache.org
CC: hbase-u...@hadoop.apache.orgmailto:hbase-u...@hadoop.apache.org
Date: Fri, 16 Jul 2010 12:34:36 +0100
Subject: Re: Row level locking?
Currently a row is part of a region
12 matches
Mail list logo
