If we're only referring to a single row, there's no distributed lock. The lock lives within the region. These row locks are already a part of HRegion so doing these atomic primitives is quite simple, whereas doing something with DLs becomes significantly more complex.
Distributed locks would be necessary if these atomic operations crossed rows or region boundaries. In our cases, we're always referring to a single row (and actually single column). Row locks are already available for these cases. JG -----Original Message----- From: Andrew Purtell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 12:49 PM To: [email protected] Subject: RE: HBase concurrent access and BatchUpdate obj I think a lot can be done with the atomic primitives increment, decrement, test-and-increment-if, and test-and-decrement-if, but there is already Zookeeper for DLM right? - Andy --- On Wed, 8/6/08, Jonathan Gray <[EMAIL PROTECTED]> wrote: > From: Jonathan Gray <[EMAIL PROTECTED]> > Subject: RE: HBase concurrent access and BatchUpdate obj > To: [email protected] > Date: Wednesday, August 6, 2008, 12:02 PM > Chris, > > That could also work for the simple case. Exposing the row > locks allows us to do anything we want "within a row > transaction" so to speak; many reads, writes... > > Jean-Adrien, > > I will probably work up an additional patch to add an > increment insert which does the second method I described > earlier. I think this is actually might be a common enough > use case that others would want it as well. > > > JG
