thanks Doug...so you saying something like this called from diff threads in
a fairly loaded system would not be much of a concern?

    log(String something){
     HTable htable = new HTable();
     htable.incrementColumnValue(key,columnFamily,columnQualifier,1L);
    }


On Thu, Jul 21, 2011 at 10:01 AM, Doug Meil
<[email protected]>wrote:

>
> 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
> >>
> >>
>
>

Reply via email to