On Mon, Apr 4, 2011 at 12:45 AM, Ashish Shinde <[email protected]> wrote: > We are using hbase to power a web application. The current > implementation of the data access classes maintain a static HTable > instance to read and write. The reason being getting hold of HTable > instance looks costly. > > In this scenario the HTable instances could more or less be perpetually > cached. Is it reasonable to assume that HTables do not have some > inherent timeout and are threadsafe across gets and puts?
Hi Ashish, if you're interested in a thread-safe, scalable HBase client, take a look at asynchbase: https://github.com/stumbleupon/asynchbase It was designed from the ground up to be thread-safe, you only need one instance of HBaseClient per cluster, regardless of how many tables you're going to interact with. It also greatly outperforms HTable, especially in write-heavy workloads, because it uses far fewer threads and has less lock contention. -- Benoit "tsuna" Sigoure Software Engineer @ www.StumbleUpon.com
