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<he...@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.
