Sequential numbering is a special case of "now". In large diameters, now
gets very expensive. This is a special case of that assertion. If there is
a way to get away from this presumption of the need for sequential
numbering, you will be miles better off.
ZK can do better than you suggest. Incrementing a counter does involve
potential contention, but you will very likely be able to get to pretty high
rates before the optimistic locking begins to fail. If you code your update
with a few tries at full speed followed by some form of retry back-off, you
should get pretty close to the best possible performance.
You might also try building a lock with an ephemeral file before updating
the counter. I would expect that this will be slower than the back-off
option if only because involves more transactions in ZK. IF you wanted to
get too complicated for your own good, you could have a secondary strategy
flag that is only sampled by all clients every few seconds and is updated
whenever a client needs to back-off more than say 5 steps. If this flag has
been updated recently, then clients should switch to the locking protocol.
You might even have several locks so that you don't exclude all other
updaters, merely thin them out a bit. This flagged strategy would run as
fast as optimistic locking as long as optimistic locking is fast and then
would limit the total number of transactions needed under very high load.
On Thu, Aug 5, 2010 at 3:31 PM, Jonathan Holloway <
> My so far involve:
> a) Creating a node with PERSISTENT_SEQUENTIAL then deleting it - this gives
> me the monotonically increasing number, but the sequence number isn't
> b) Storing the sequence number in the data portion of a persistent node -
> then updating this (using the version number - aka optimistic locking).
> problem with this is that under high load I'm assuming there'll be a lot of
> contention and hence failures with regards to updates.