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 <[email protected]>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: [email protected] > homepage: http://germoglio.googlepages.com >
