You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by large data <lr...@gmail.com> on 2011/07/21 01:44:38 UTC
thread safety of incrementColumnValue
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
Re: thread safety of incrementColumnValue
Posted by Ted Yu <yu...@gmail.com>.
In getTable():
synchronized(queue) {
table = queue.poll();
}
You can see similar construct in putTable().
So using HTablePool among multiple threads is safe.
On Sat, Jul 23, 2011 at 5:33 AM, 陈加俊 <cj...@gmail.com> wrote:
> Yes , executed under heavy loads by n-threads. Is there anything I need to
> be
> worried about?
>
> On Fri, Jul 22, 2011 at 12:17 PM, large data <lr...@gmail.com> wrote:
>
> > thanks ted..
> >
> > Are there any best practices around usage of HTablePool? For a code
> > structure like this
> >
> > HTablePool pool = new HTablePool();
> > String tableName="table";
> >
> > public void log(query) throws Exception {
> >
> > HTable table = pool.getTable(Bytes.toBytes(tableName);
> > ...
> > ...
> > //done
> > pool.putTable(Bytes.toBytes(tableName);
> >
> > }
> >
> > executed under heavy loads by n-threads. Is there anything I need to be
> > worried about?
> >
> > On Thu, Jul 21, 2011 at 11:21 AM, Ted Yu <yu...@gmail.com> wrote:
> >
> > > Please reuse HTable instances through HTablePool.
> > >
> > >
> > >
> > > On Jul 21, 2011, at 10:08 AM, large data <lr...@gmail.com> wrote:
> > >
> > > > 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
> > > > <do...@explorysmedical.com>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" <lr...@gmail.com> 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
> > > >>> <do...@explorysmedical.com>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" <lr...@gmail.com> 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
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> > >
> >
>
>
>
> --
>
> 陈加俊 项目经理
> 优讯时代（北京）网络技术有限公司
> 优讯网 www.uuwatch.com
>
> 地址：北京市海淀区上地信息路2号D栋412
>
> 电话：010-82895510
> 传真：010-82896636
> 手机：15110038983
> 电邮：*cjjvictory@gmail.com*
>
Re: thread safety of incrementColumnValue
Posted by 陈加俊 <cj...@gmail.com>.
Yes , executed under heavy loads by n-threads. Is there anything I need to
be
worried about?
On Fri, Jul 22, 2011 at 12:17 PM, large data <lr...@gmail.com> wrote:
> thanks ted..
>
> Are there any best practices around usage of HTablePool? For a code
> structure like this
>
> HTablePool pool = new HTablePool();
> String tableName="table";
>
> public void log(query) throws Exception {
>
> HTable table = pool.getTable(Bytes.toBytes(tableName);
> ...
> ...
> //done
> pool.putTable(Bytes.toBytes(tableName);
>
> }
>
> executed under heavy loads by n-threads. Is there anything I need to be
> worried about?
>
> On Thu, Jul 21, 2011 at 11:21 AM, Ted Yu <yu...@gmail.com> wrote:
>
> > Please reuse HTable instances through HTablePool.
> >
> >
> >
> > On Jul 21, 2011, at 10:08 AM, large data <lr...@gmail.com> wrote:
> >
> > > 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
> > > <do...@explorysmedical.com>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" <lr...@gmail.com> 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
> > >>> <do...@explorysmedical.com>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" <lr...@gmail.com> 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
> > >>>>
> > >>>>
> > >>
> > >>
> >
>
--
陈加俊 项目经理
优讯时代（北京）网络技术有限公司
优讯网 www.uuwatch.com
地址：北京市海淀区上地信息路2号D栋412
电话：010-82895510
传真：010-82896636
手机：15110038983
电邮：*cjjvictory@gmail.com*
Re: thread safety of incrementColumnValue
Posted by large data <lr...@gmail.com>.
thanks ted..
Are there any best practices around usage of HTablePool? For a code
structure like this
HTablePool pool = new HTablePool();
String tableName="table";
public void log(query) throws Exception {
HTable table = pool.getTable(Bytes.toBytes(tableName);
...
...
//done
pool.putTable(Bytes.toBytes(tableName);
}
executed under heavy loads by n-threads. Is there anything I need to be
worried about?
On Thu, Jul 21, 2011 at 11:21 AM, Ted Yu <yu...@gmail.com> wrote:
> Please reuse HTable instances through HTablePool.
>
>
>
> On Jul 21, 2011, at 10:08 AM, large data <lr...@gmail.com> wrote:
>
> > 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
> > <do...@explorysmedical.com>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" <lr...@gmail.com> 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
> >>> <do...@explorysmedical.com>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" <lr...@gmail.com> 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
> >>>>
> >>>>
> >>
> >>
>
Re: thread safety of incrementColumnValue
Posted by Ted Yu <yu...@gmail.com>.
Please reuse HTable instances through HTablePool.
On Jul 21, 2011, at 10:08 AM, large data <lr...@gmail.com> wrote:
> 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
> <do...@explorysmedical.com>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" <lr...@gmail.com> 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
>>> <do...@explorysmedical.com>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" <lr...@gmail.com> 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
>>>>
>>>>
>>
>>
Re: thread safety of incrementColumnValue
Posted by large data <lr...@gmail.com>.
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
<do...@explorysmedical.com>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" <lr...@gmail.com> 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
> ><do...@explorysmedical.com>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" <lr...@gmail.com> 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
> >>
> >>
>
>
Re: thread safety of incrementColumnValue
Posted by Doug Meil <do...@explorysmedical.com>.
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" <lr...@gmail.com> 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
><do...@explorysmedical.com>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" <lr...@gmail.com> 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
>>
>>
Re: thread safety of incrementColumnValue
Posted by large data <lr...@gmail.com>.
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 <do...@explorysmedical.com>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" <lr...@gmail.com> 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
>
>
Re: HTablePool for Reading Performance
Posted by hm...@tsmc.com.
Hi,
I've loaded 30 oracle tables into HBase successfully. All these columns are
in a single columnFamily.
My java program is trying to random read a few data from the first table to
the last.
Like Bill of Material, my user will pass one or a few products to my
application which will
return each product's materials to user. For that, I try to create thread
in a machine for fetching data from Hbase quickly.
Each thread shares one configure.
Following is my thread reading result:
Thread Count duration(second)
1 69
2 97,98
3 106,117,119
10
193,193,198,203,203,207,209,212,216,217
That would be better if the duration can keep at around 70~80 while 10
threads are running.
Any suggestions? Thank you very much
>Our cluster with 20 machines(1U server, 4 cores, 12G RAM)
>Hadoop 20 machines
>Zookeeper 3
>RegionServer 10
>Hadoop version hadoop-0.20.2-cdh3u0
>HBase version hbase-0.90.1-cdh3u0
Fleming Chiu(邱宏明)
Ext: 707-2260
Be Veg, Go Green, Save the Planet!
jdcryans@gmail.com
To
Sent by: user@hbase.apache.org
jdcryans@gmail.com cc
Subject
2011/07/22 上午 05:28 Re: HTablePool for Reading Performance
Please respond to
user@hbase.apache.org
Inline.
J-D
> I am trying to start multiple threads in a client to read data from
Hbase.
> These threads seem to share only one connection, which resulted in
> increasing latency.
Data on that?
> HTablePool can create multiple connections, right?
Multiple HTable, but they all share one connection to each RS and the
queries/answers are multiplexed.
> I am using two ways to scan HBASE data.
> One is scanning by Key value, the other is scanning by index
> (hbase-transactional-tableindexed IndexedTable)
> I don't know how to adopt HTablePool for my IndexedTable.
I think you just need to pass a class that implements
HTableInterfaceFactory to the constructor and that creates
IndexedTable instead of HTable.
J-D
---------------------------------------------------------------------------
TSMC PROPERTY
This email communication (and any attachments) is proprietary information
for the sole use of its
intended recipient. Any unauthorized review, use or distribution by anyone
other than the intended
recipient is strictly prohibited. If you are not the intended recipient,
please notify the sender by
replying to this email, and then delete this email and any copies of it
immediately. Thank you.
---------------------------------------------------------------------------
Re: HTablePool for Reading Performance
Posted by Jean-Daniel Cryans <jd...@apache.org>.
Inline.
J-D
> I am trying to start multiple threads in a client to read data from Hbase.
> These threads seem to share only one connection, which resulted in
> increasing latency.
Data on that?
> HTablePool can create multiple connections, right?
Multiple HTable, but they all share one connection to each RS and the
queries/answers are multiplexed.
> I am using two ways to scan HBASE data.
> One is scanning by Key value, the other is scanning by index
> (hbase-transactional-tableindexed IndexedTable)
> I don't know how to adopt HTablePool for my IndexedTable.
I think you just need to pass a class that implements
HTableInterfaceFactory to the constructor and that creates
IndexedTable instead of HTable.
J-D
HTablePool for Reading Performance
Posted by hm...@tsmc.com.
Hi,
I am trying to start multiple threads in a client to read data from Hbase.
These threads seem to share only one connection, which resulted in
increasing latency.
HTablePool can create multiple connections, right?
I am using two ways to scan HBASE data.
One is scanning by Key value, the other is scanning by index
(hbase-transactional-tableindexed IndexedTable)
I don't know how to adopt HTablePool for my IndexedTable.
Any ideas? Thank you very much.
Fleming Chiu(邱宏明)
Ext: 707-2260
Be Veg, Go Green, Save the Planet!
---------------------------------------------------------------------------
TSMC PROPERTY
This email communication (and any attachments) is proprietary information
for the sole use of its
intended recipient. Any unauthorized review, use or distribution by anyone
other than the intended
recipient is strictly prohibited. If you are not the intended recipient,
please notify the sender by
replying to this email, and then delete this email and any copies of it
immediately. Thank you.
---------------------------------------------------------------------------
Re: thread safety of incrementColumnValue
Posted by Doug Meil <do...@explorysmedical.com>.
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" <lr...@gmail.com> 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