Thanks for the explanation Ryan.

-chris

On Dec 12, 2010, at 3:16 PM, Ryan Rawson wrote:

> Ok javadoc cruft ahoy.
> 
> So back to the core issue about persistence, we promise that if we ack
> that your data won't be lost (IF you are running under an
> HDFS-200/append qualified hdfs, cdh3b2+ is one such, building from the
> append-20-branch in ASF is another).  But what happens if the
> regionserver crashes?  What about those transactions in flight?  Well
> we can't promise (nor does any database system promise this, including
> oracle, mysql, etc) that unacked Put operations won't be recovered,
> and this CAN happen (seen it in my testing).  Basically we make a
> minimal level of promise, and we can overdeliver sometimes.
> 
> As for batch puts, for efficiency sakes they are aggregated in the
> HLog so they should exist as an single HLog entry to be recovered or
> not.  Don't mistake this for transactions, since it only applies to
> rows hosted on the same regionserver.  If your batch set covers
> multiple regionservers, then you will see multiple RPCs for each, each
> one in a different HLog and thus no real transaction support.
> 
> -ryan
> 
> On Sat, Dec 11, 2010 at 2:37 PM, Chris Tarnas <[email protected]> wrote:
>> It surprised me when I read it and wondered if something special was going 
>> on for the Thrift API. I saw the comment in the Hbase.thrift API file here:
>> 
>> http://svn.apache.org/viewvc/hbase/trunk/src/main/resources/org/apache/hadoop/hbase/thrift/Hbase.thrift?view=markup
>> 
>> Look at the comment for the mutateRows method at around line 405.
>> 
>> thanks,
>> -chris
>> 
>> On Dec 11, 2010, at 11:12 AM, Stack wrote:
>> 
>>> Where do you see that?  HBase is not transactional.
>>> Thanks Chris,
>>> St.Ack
>>> 
>>> On Fri, Dec 10, 2010 at 2:57 PM, Chris Tarnas <[email protected]> wrote:
>>>> I was looking through the thirft API again and noticed that it said if a 
>>>> transaction - comprised of updates to one or more rows - throws an 
>>>> exception then the whole transaction is aborted. Does this mean that it is 
>>>> atomic and none of the updates will be executed or could some subset of 
>>>> them be executed (which I assumed was the case before I read the comments 
>>>> again recently).
>>>> 
>>>> thanks
>>>> -chris
>>>> 
>>>> 
>> 
>> 

Reply via email to