Bob, In my experience, it does make sense to pool HTable instances.
Internally we use something we call HBaseRef that does this for us. The general API of it is just HBaseRef.getTable(String) and HBaseRef.putTable(HTable). This was designed way back in 0.2.1 so might be a bit overkill today. The two things to take in to account w.r.t. HTable: - Instantiating a new HTable is costly, often times an order of magnitude or more slower than a single random read. This is really what we want to avoid in a web-facing app w/ low latency requirements. - All testing and benchmarking has shown that there is no performance difference for READS in different threads sharing a single HTable. WRITES do benefit from using a unique HTable per thread. So in practice, you do want to pool/reuse HTable instances because you want to keep latency low. Might be useful to actually make an HTablePool as part of HBase client utilities. There's nothing complex about it, but if you are interested in seeing code let me know and I can file an issue. JG On Thu, April 23, 2009 12:25 am, Bob Schulze wrote: > Is Hbase' Connection manager already taking care of the connection > pooling? Does it make sense to Pool HTable instances in a multi-threaded > (web like) usage scenario? > > > Thx, > > > Bob > > >
