A HTable object is not thread safe for writing. You'll need to watch for that.
So use the pool of HTables as J-D suggests, or instantiate a group of worker threads and allocate one HTable object for each at the top of run() before entering the work loop. - Andy ----- Original Message ---- > From: Jean-Daniel Cryans <jdcry...@apache.org> > To: hbase-user@hadoop.apache.org > Sent: Fri, January 15, 2010 5:40:14 PM > Subject: Re: HBase as DB tier for Tomcat - best practices to instantiate > HTables? > > You want to keep using a pool of HTables, see > http://hadoop.apache.org/hbase/docs/r0.20.2/api/org/apache/hadoop/hbase/client/HTablePool.html > > J-D > > On Fri, Jan 15, 2010 at 5:35 PM, Jeyendran Balakrishnan > wrote: > > What's the best way to instantiate HTables when the HBase cluster is > > being accessed from client code running inside a Tomcat web app? The web > > app dooes the typical CRUD operations [but no table alteration]. > > > > I read from the lists some time ago that instantiating a HTable in > > servlet request is not advisable, since instantiating HTable is a bit > > slow [accesses the meta regions?]. > > > > So is the best practice for web apps to instantiate a HTable once at > > startup and cache in the servlet context, and re-use it every request? > > > > In that case, is this thread safe [since each request spawns a different > > thread]? On the other hand, syncing on the single HTable instance at the > > web application level also slows down requests when contending for this > > one instance. > > > > Also, is holding on to a single HTable instance in a long-running web > > app a reliable approach? > > > > Or is it better to bite the bullet and instantiate an HTable per request > > after all? > > > > Finally, has anybody looked into or have some kind of HTable pool [like > > DB connection pools], which is a sort of medium between one HTable per > > web app and one HTable per request? > > > > Any advice on best practices from the community would be greatly > > appreciated. > > > > Thanks, > > Jeyendran > > > >
