Rethinking about it, it would be better to have clear indication and
simply state that the class is not thread-safe (the client of this class
should know what it means and take appropriate measures).
Opening the door to special cases can be dangerous/misleading,
especially when the implementation can change.
A reference to HTablePool would also be useful to drive users to use the
pool mechanism out-of-the-box.
Thx.
On 16/08/11 15:44, Doug Meil wrote:
I agree that the Javadoc should be updated, and it would be less confusing
for users not to have any exceptions (e.g., here's an edge-case where it
works, otherwise it's a very bad idea).
I'll take care of it.
Thanks!
On 8/16/11 8:42 AM, "Eric Charles"<[email protected]> wrote:
If HTable is not thread-safe for R/W, should the javadoc updated to
something like?:
"This class is not thread safe for any operation (Read or Write). If the
same HTable instance is used among multiple threads, you need to
carefully synchronize access to the single resource in your code,
otherwise saved and/or read data can be corrupted."
Or maybe is HTable still thread-safe for simple Gets only?
Thx.
On 14/08/11 15:29, Doug Meil wrote:
I wouldn't do it... Some of the other committers can comment more on
this, but there is state cached in HTable instances when scanning.
E.g.,...
protected class ClientScanner implements ResultScanner {
private final Log CLIENT_LOG = LogFactory.getLog(this.getClass());
// HEADSUP: The scan internal start row can change as we move
through
table.
private Scan scan;
private boolean closed = false;
// Current region scanner is against. Gets cleared if current
region
goes
// wonky: e.g. if it splits on us.
private HRegionInfo currentRegion = null;
private ScannerCallable callable = null;
private final LinkedList<Result> cache = new LinkedList<Result>();
private final int caching;
private long lastNext;
// Keep lastResult returned successfully in case we have to reset
scanner.
private Result lastResult = null;
On 8/14/11 3:24 AM, "Yi Liang"<[email protected]> wrote:
From the javadoc of HTable:
"This class is not thread safe for updates; the underlying write buffer
can be corrupted if multiple threads contend over a single HTable
instance."
Does that mean HTable is thread safe if we only use it to get rows?
Thanks,
Yi
--
Eric
http://about.echarles.net
--
Eric
http://about.echarles.net
