hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Tarnas <...@email.com>
Subject Re: thirft mutateRows transaction
Date Mon, 13 Dec 2010 05:05:38 GMT
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 <cft@email.com> 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 <cft@email.com> 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
>>>> 
>>>> 
>> 
>> 


Mime
View raw message