(b) BUT:
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. HOWEVER: 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 < jonathan.hollo...@gmail.com> wrote: > 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 > contiguous > b) Storing the sequence number in the data portion of a persistent node - > then updating this (using the version number - aka optimistic locking). > The > 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. >
