hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Reed <br...@yahoo-inc.com>
Subject Re: How to ensure trasaction create-and-update
Date Tue, 30 Mar 2010 20:00:16 GMT
i agree with ted. i think he points out some disadvantages with trying 
do do more. there is a slippery slope with these kinds of things. the 
implementation is complicated enough even with the simple model that we use.

ben

On 03/29/2010 08:34 PM, Ted Dunning wrote:
> I perhaps should not have said power, except insofar as ZK's strengths are
> in reliability which derives from simplicity.
>
> There are essentially two common ways to implement multi-node update.  The
> first is the tradtional db style with begin-transaction paired with either a
> commit or a rollback after some number of updates.  This is clearly
> unacceptable in the ZK world if the updates are sent to the server because
> there can be an indefinite delay between the begin and commit.
>
> A second approach is to buffer all of the updates on the client side and
> transmit them in a batch to the server to succeed or fail as a group.  This
> allows updates to be arbitrarily complex which begins to eat away at the
> "no-blocking" guarantee a bit.
>
> On Mon, Mar 29, 2010 at 8:08 PM, Henry Robinson<henry@cloudera.com>  wrote:
>
>    
>> Could you say a bit about how you feel ZK would sacrifice power and
>> reliability through multi-node updates? My view is that it wouldn't: since
>> all operations are executed serially, there's no concurrency to be lost by
>> allowing multi-updates, and there doesn't need to be a 'start / end'
>> transactional style interface (which I do believe would be very bad).
>>
>> I could see ZK implement a Sinfonia-style batch operation API which makes
>> all-or-none updates. The reason I can see that it doesn't already allow
>> this
>> is the avowed intent of the original ZK team to keep the API as simple as
>> it
>> can reasonably be, and to not introduce complexity without need.
>>
>>      


Mime
View raw message