There is no way that this kind of action would ever be performant, with 4 rpc calls.
Have a look at the 'atomicIncrement' call... -ryan On Fri, May 8, 2009 at 6:57 PM, Guilherme Germoglio <germog...@gmail.com>wrote: > thank you, Ryan. > > what about changing a row value to something that depends on its previous > value? An atomic increment of an integer, for example. I'm thinking > something like the following (in pseudocode - sort of :-): > > lock = htable.lockRow(row); > value = htable.getRow(row, lock); > value = doSomething(value); > batchupdate.put(row, column, value); > htable.commit(batchupdate, lock); > htable.unlockRow(lock); > > On Fri, May 8, 2009 at 8:51 PM, Ryan Rawson <ryano...@gmail.com> wrote: > > > Hey, > > > > You can bundle any number of operations (put and delete) to 1 row with > > BatchUpdate thus obviating the need for using explicit row locks (the > > server > > does the locks internally as well, so in this case you are locking > twice). > > > > -ryan > > > > On Fri, May 8, 2009 at 4:29 PM, Guilherme Germoglio <germog...@gmail.com > > >wrote: > > > > > Hello, > > > > > > I've been running some tests using HTable.lockRow but I think it is not > > > performing well. One of my tests is quite simple: run several threads > > that > > > will execute the following lines for the same row: > > > > > > RowLock rowLock = htable.lockRow(Bytes.toBytes(row)); > > > htable.commit(batchupdate, rowLock); > > > htable.unlockRow(rowLock); > > > > > > where the batchupdate only does a single "put" on a single column. > > > > > > The problem is that it is running very very slow when I use only 20 > > > threads: > > > about 30 minutes against the 6~10 seconds of running with 10 threads. > > Also, > > > when using 20 threads, some *java.io.IOException: java.io.IOException: > > > Invalid row lock* messages are printed. > > > > > > Since it is the first time I'm using RowLocks, I'm not sure if the > > problem > > > is in my test or in HBase. So, I'm asking you for help. > > > > > > I'm using hbase 0.19.2 (rc) in pseudo-distributed mode on a mac book, > but > > > the behavior is the same when using 0.19.0. Logs, hbase-site.xml (which > > is > > > the default) and the test can be found on the following link: > > > > > > http://germoglio.googlepages.com/logs.zip > > > > > > Please notice that although this test doesn't make much sense of > locking, > > > the idea is to evolve it in order to perform a few operations besides > the > > > only single put between lockRow and unlockRow methods. > > > > > > Thank you very much, > > > > > > -- > > > Guilherme > > > > > > msn: guigermog...@hotmail.com > > > homepage: http://germoglio.googlepages.com > > > > > > > > > -- > Guilherme > > msn: guigermog...@hotmail.com > homepage: http://germoglio.googlepages.com >
