>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

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

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

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

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

Hi,
I opened https://issues.apache.org/jira/browse/HBASE-4205 for this.
Eric

On 16/08/11 16:28, Eric Charles wrote:
> 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