Hey, HTable instances are not really thread safe at this time. You can cache them, check out HTablePool. But the creation cost of a HTable instance isnt that high, the actual TCP socket creation and management is done at a lower level and all HTable interfaces share these common caches and sockets. So you can create a number of HTable instances without creating a large number of sockets.
Oh and be sure to re-use the same Configuration object, or else you'll end up with multiple sockets. This is because we use the Config object to know when two HTables are accessing the same cluster. -ryan On Mon, Apr 4, 2011 at 12:45 AM, Ashish Shinde <[email protected]> wrote: > Hi, > > 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? > > Thanks and regards, > - Ashish > > >
