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
> is the avowed intent of the original ZK team to keep the API as simple as
> can reasonably be, and to not introduce complexity without need.