Hi there- Especially with respect to the caching, HBase has a block cache so I think it would be a good idea to review the architecture chapter....
http://hbase.apache.org/book.html#architecture On 4/13/12 3:45 AM, "Bing Li" <lbl...@gmail.com> wrote: >NNever, > >Thanks so much for your answers! > > >On Fri, Apr 13, 2012 at 10:50 AM, NNever <nnever...@gmail.com> wrote: > >> 1. A pre-row lock is here during the update, so other clients will block >> whild on client performs an update.(see HRegion.put 's annotaion), no >> exception. >> In the client side, while a process is updating, it may not reach the >> buffersize so the other process may read the original value, I think. >> >> 2. What kind of inconsistency? different value on the same row's >> qualifier? >> > >The inconsistency means for the same retrieval, such as a scan, different >values are got in different threads for the multiple instances of a HTable >in them, respectively. Is it possible? > >In my case, the little bit inconsistency is not so critical. So I will not >worry about the thread-safety issue. It must be fine? > > > >> >> 3.I don't know the truely realize in code. There Is caching, but >> everytime you call methods like Htable.get, it still need connect to >>server >> to retrieve data‹‹so, not as fast as in memory, isn't it? >> > >I plan to design a read-only mechanism except when a >periodically-updatinge >in with HBase for my system to raise the performance. Locking must affect >the performance. If caching is not fast enough in HBase, the design might >not be good? > >Thanks again! > >Best, >Bing > > >> >> Best regards, >> nn >> >> 2012/4/13 Bing Li <lbl...@gmail.com> >> >>> Dear Iars, >>> >>> Thanks so much for your reply! >>> >>> In my case, I need to overwrite or update a HTable. If reading during >>>the >>> process of updating or overwriting, any exceptions will be thrown by >>> HBase? >>> >>> If multiple instances for a HTable are used by multiple threads, there >>> must >>> be inconsistency among them, right? >>> >>> I guess caching must be done in HBase. So retrieving in HTable must be >>> almost as fast as in memory? >>> >>> Best regards, >>> Bing >>> >>> On Fri, Apr 13, 2012 at 6:17 AM, lars hofhansl <lhofha...@yahoo.com> >>> wrote: >>> >>> > Hi Bing, >>> > >>> > Which part? The server certainly is thread safe. >>> > The client is not, at least not all the way through. >>> > >>> > The main consideration is HTable, which is not thread safe, you need >>>to >>> > create one instance for each thread >>> > (HBASE-4805 makes that much cheaper), store the HTable in a >>>ThreadLocal >>> > after creation, or use HTablePool. >>> > >>> > Please let me know if that answers your question. >>> > >>> > Thanks. >>> > >>> > -- Lars >>> > >>> > >>> > ----- Original Message ----- >>> > From: Bing Li <lbl...@gmail.com> >>> > To: hbase-u...@hadoop.apache.org; user <user@hbase.apache.org> >>> > Cc: >>> > Sent: Thursday, April 12, 2012 3:10 PM >>> > Subject: Is HBase Thread-Safety? >>> > >>> > Dear all, >>> > >>> > Is HBase thread-safety? Do I need to consider the consistency issue >>>when >>> > manipulating HBase? >>> > >>> > Thanks so much! >>> > >>> > Best regards, >>> > Bing >>> > >>> > >>> >> >>
