> From: [email protected]
> Date: Wed, 10 Nov 2010 11:57:56 -0800
> Subject: Re: Why and When to use HTablePool?
> To: [email protected]
>
> On Tue, Nov 9, 2010 at 8:14 AM, Michael Segel <[email protected]>
> wrote:
> > The use case for the HTablePool is pretty much the same as any application
> > where you need to fetch a resource from a pool rather than constantly
> > instantiate them.
> >
> > Really the driving factor on which to use (HTable or HTablePool) is going
> > to be your use case, or rather what it is you hope to achieve.
>
> HTable isn't thread-safe when you write to HBase. I think that's why
> HTablePool exists.
>
> If you want a highly scalable HBase client in which you don't need to
> think about pools or thread safety, you can take a look at asynchbase:
> http://github.com/stumbleupon/asynchbase
>
> --
> Benoit "tsuna" Sigoure
> Software Engineer @ www.StumbleUpon.com
Ok...
You really don't want to do multi-threading within a m/r job.
I mean, yes you can, but you don't really want to do it unless you have a
really good reason.
But to your point, HBase can be used outside of a m/r job which is what I was
talking about in the paragraph you cut from my post.
There where you have a multi-threaded client, you'd want to use the HTablePool.
And again, the driving factor will be your use case... even in a multi-threaded
client, you could still use HTable, albeit you need to make sure that you
instantiate an instance within the thread.
