Michael, Stack is exactly right. RowLocks are definitely intended to be used in this way (this is how we use them, primarily as a method for an atomic read/write operation).
You need to explicitly unlock them, but also be aware that they have a lease just as a scanner does, so they will always eventually unlock themselves (in the case that your client dies, etc). JG > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > stack > Sent: Monday, February 16, 2009 8:28 AM > To: [email protected] > Subject: Re: Question on RowLock > > See how you can lock a row -- it returns a RowLock instance -- here > http://hadoop.apache.org/hbase/docs/r0.19.0/api/org/apache/hadoop/hbase > /client/HTable.html#lockRow(byte[]). > Then see how elsewhere in HTable, all operations optionally take a > RowLock > instance. Unlock the row when done using this method: > http://hadoop.apache.org/hbase/docs/r0.19.0/api/org/apache/hadoop/hbase > /client/HTable.html#unlockRow(org.apache.hadoop.hbase.client.RowLock) > . > > A single server at any one time will be hosting the region that > contains the > row you are locking. When you get a RowLock its held by this host. > Ergo, > no need for it to be distributed. > > St.Ack > > > On Mon, Feb 16, 2009 at 8:07 AM, Michael Dagaev > <[email protected]>wrote: > > > Hi, all > > > > Is this class intended for public use? > > > > Can I use it to lock a row, read and update the row data > > and unlock the row ? I guess it is not a distributed lock I need > > but I want to be sure ... > > > > What I need is a some way to lock a row, read and update the data > > and unlock the row after the update. > > > > Thank you for your cooperation, > > M. > >
