re: "Now creating an instance of an Htable is quite expensive on a per thread basis."
Connection/metadata is managed statically. Creating Htables instances isn't that heavyweight. On 7/21/11 11:30 AM, "large data" <[email protected]> wrote: >Thanks Doug! this is very informative. Now creating an instance of an >HTable >is quite expensive on a per thread basis. Reading through the docs I found >this >http://hbase.apache.org/apidocs/index.html?org/apache/hadoop/hbase/client/ >HTablePool.html > >Are there any best practices using HTablePool? HTablePool >sounds analogous to DB connection pools to me but I am not sure how >HTablePool.get() would work under multithreaded environment. > >thanks > > >On Wed, Jul 20, 2011 at 6:28 PM, Doug Meil ><[email protected]>wrote: > >> >> Hi there- >> >> I think there are two subjects here: >> >> >> 1) the fact that HTable isn't thread-safe >> >> 2) how counters work >> >> Even if you are incrementing counters, you shouldn't be sharing HTable >> instances across threads. >> >> Counters get updated atomically on the RS, not on the client. >> >> Counter behavior isn't in the Hbase book and it needs to be. I'll add >>it >> to the list. >> >> >> On 7/20/11 7:44 PM, "large data" <[email protected]> wrote: >> >> >I have an HTable instance instantiated as part of a singleton service. >> >This >> >singleton service is called from different threads from different >>parts of >> >the app. Reading through the HTable docs suggests not to use single >>HTable >> >instance for updates, if it's true how can incrementColumnValue provide >> >thread safety? >> > >> >thanks >> >>
