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 contended rather than sleep and wait for the lock to be acquired (which would consume an RPC thread and could result in deadlock). The client can then adopt a backoff/retry lock policy if on the client side if tryLock returns null. There has also been some discussion at https://issues.apache.org/jira/browse/HBASE-2332 about replacing the client-side row lock APIs which perform mandatory locking with advisory locks, which should also avoid any server-side blocking/deadlock when implemented.
Best regards, Mike On Fri, Jul 16, 2010 at 2:07 PM, Justin Cohen <[email protected]>wrote: > What kind of trouble? I do quite a bit of: > > l = lock(row); > val = get(row); > /* modify val */ > put(row, val); > unlock(l); > > Is there an alternative? > > -justin > > > On 7/16/10 4:02 PM, Ryan Rawson wrote: > >> Also be very wary of using any >> of the explicit row locking calls, they are generally trouble for more >> or less everyone. >> >
