Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> HTable thread safe for scans?


Copy link to this message
-
HTable thread safe for scans?
Hi,

Please see https://issues.apache.org/jira/browse/HBASE-7035#comment-13708295 for context. We added a while ago some wording around why HTable is not thread safe and how you should use HTablePool instead. I do get the point about the local write buffer, and also maybe if you do Get's or any Batch/Multi operation. But what about scans? I mean, looking at the code, it does not seem to be interfering with HTable at all, it gets handed in the connection reference (the ClientScanner) and since after that it has its own ID based counterpart on the server side, it seems that the thread which created the scan is safe to release the table instance to the pool again.

In other words, if a thread (#1) creates a scanner, then another thread (#2) is allowed to use the table instance used by the first thread, would thread #1 have any issues with using the already created scanner? I'd say no, reading the code.

If that is the case, we should fix the JavaDoc.

Lars
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB