Used to communicate with a single HBase table.
This class is not thread safe for reads nor write.
In case of writes (Put, Delete), the underlying write buffer can be corrupted if multiple threads contend over a single HTable instance.
In case of reads, some fields used by a Scan are shared among all threads. The HTable implementation can either not contract to be safe in case of a Get
To access a table in a multi threaded environment, please consider using the {@link HTablePool} class to create your HTable instances.
Instances of HTable passed the same {@link Configuration} instance willshare connections to servers out on the cluster and to the zookeeper ensemble as well as caches of region locations. This is usually a *good* thing and it is recommended to reuse the same configuration object for all your tables. This happens because they will all share the same underlying {@link HConnection} instance. See {@link HConnectionManager} for more onhow this mechanism works.
{@link HConnection} will read most of theconfiguration it needs from the passed {@link Configuration} on initialconstruction. Thereafter, for settings such as hbase.client.pause
, hbase.client.retries.number
, and hbase.client.rpc.maxattempts
updating their values in the passed {@link Configuration} subsequent to {@link HConnection} constructionwill go unnoticed. To run with changed values, make a new {@link HTable} passing a new {@link Configuration} instance that has thenew configuration.
Note that this class implements the {@link Closeable} interface. When aHTable instance is no longer required, it *should* be closed in order to ensure that the underlying resources are promptly released. Please note that the close method can throw java.io.IOException that must be handled.
@see HBaseAdmin for create, drop, list, enable and disable of tables.
@see HConnection
@see HConnectionManager