Thanks a lot for clarifying Ted!
I also realized there's an "offsetLock" in HFileReaderV2's readBlock
function, that prevents multiple threads
from placing a certain block in cache, while the ConcurrentHashMap makes
this access thread-safe.

Thanks!
--
Bharath Ravi


On 27 February 2013 14:02, Ted Yu <[email protected]> wrote:

> From the javadoc:
>
>    * Cache the block with the specified name and buffer.
>
>    * <p>
>
>    * It is assumed this will NEVER be called on an already cached block.
>  If
>
>    * that is done, an exception will be thrown.
> The underlying map is a ConcurrentHashMap, providing concurrency support.
>
> Cheers
>
> On Wed, Feb 27, 2013 at 10:57 AM, Bharath Ravi <[email protected]
> >wrote:
>
> > Hi all,
> >
> > I'm working on a research project in improving caching in HBase and
> similar
> > stores.
> >
> > Going over the HFileReader and LruBlockCache code, I couldn't figure out
> if
> > updates to the Block cache are synchronized.
> >
> > If I gather correctly, there is no locking at work, and concurrent
> > "cacheBlock" calls simply throw an "already cached" exception which (I
> > assume) is safely ignored.
> >
> > Is my understanding correct?
> >
> > Thanks for the help!
> > --
> > Bharath Ravi
> >
>

Reply via email to