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
Ok,
First, I'm writing this before I've had my first cup of coffee so I am
apologizing in advance if the question is a brain dead question
Going from a relational background, some of these questions may not make sense
in the HBase world.
When does HBase acquire a lock on a row and how
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
Thanks for the response.
(You don't need to include the cc ...)
With respect to the row level locking ...
I was interested in when the lock is actually acquired, how long the lock
persists and when is the lock released.
From your response, the lock is only held on updating the row, and while
, at 6:41 PM, Michael Segel wrote:
Thanks for the response.
(You don't need to include the cc ...)
With respect to the row level locking ...
I was interested in when the lock is actually acquired, how long the lock
persists and when is the lock released.
From your response, the lock
16, 2010, at 6:41 PM, Michael Segel wrote:
Thanks for the response.
(You don't need to include the cc ...)
With respect to the row level locking ...
I was interested in when the lock is actually acquired, how long the lock
persists and when is the lock released.
From your response
that went through.
On Fri, Jul 16, 2010 at 9:16 AM, Cosmin Lehene cleh...@adobe.com wrote:
On Jul 16, 2010, at 6:41 PM, Michael Segel wrote:
Thanks for the response.
(You don't need to include the cc ...)
With respect to the row level locking ...
I was interested in when
to the row level locking ...
I was interested in when the lock is actually acquired, how long the
lock
persists and when is the lock released.
From your response, the lock is only held on updating the row, and while
the data is being written to the memory cache which is then written
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
for the response.
(You don't need to include the cc ...)
With respect to the row level locking ...
I was interested in when the lock is actually acquired, how long the lock
persists and when is the lock released.
From your response, the lock is only held on updating the row, and while
the data
13 matches
Mail list logo
