Another possible approach:
1. client generates hash code to be locked. use the first N hex digits
(eg. first 2 digits) as a filename "FN".
2. attempt to create (ephemeral) node "FN.lock". loop until this
succeeds, or abort when time budget exhausted.
3. read node "FN" containing list of hash-codes with associated expiry
times. if full hash-code does not exist, or has expired, then update list
with full hash-code and expiry time. Otherwise, you didn't get the lock.
4. release "FN.lock"
For 10K locked cards, this would give 256 nodes containing approx. 400
hash-codes. Obviously this can be scaled by increasing the number of digits
But to do this, would I need to call sync between steps 2 and 3 to ensure
the node "FN" was up-to-date - assuming I do not know if I am connected to a
primary ZK instance ? Would 10K sync calls within a 2 minute period be
On 25 February 2010 08:07, Martin Waite <waite....@googlemail.com> wrote:
> Usually, this would hold about 2k items, pushing to 10k peaks.
> My current understanding is that I cannot lock a node while I consider its
> contents, and so only the garbage remover would be allowed to remove locks
> (currently lock-clients can claim expired locks).
> The clients would simply do this:
> 1. try to create a node
> 2. if success, you have the lock, otherwise you don't
> The garbage remover would do this:
> 1. inspect node.
> 2. if expired, delete it.
> The length of time that locks are held then becomes a function of the
> length of time between garbage-removing sweeps. Perhaps that is OK.
> I cannot see how clients could safely inspect a node and overwrite the
> expiry time if it had expired. That would involve multiple steps, and so
> not be atomic.
> On 24 February 2010 22:35, Ted Dunning <ted.dunn...@gmail.com> wrote:
>> You can simply implement the current system if you like by keeping a file
>> per card in ZK that contains your lock expiration time. The garbage
>> collector would work the same way. In order to make the getchildren
>> operation in the garbage collector work well, I would recommend a
>> hierarchical naming scheme for card lock files.
>> My question would be how many elements you expect to be in that card lock
>> table. If it is less than 100K, ZK should work pretty well.
>> If you need more than that, you might consider putting locks for many
>> in a single file.
>> On Wed, Feb 24, 2010 at 11:10 AM, Martin Waite <waite....@googlemail.com
>> > 2. card-locking - to reduce the risk of payments being taken twice in
>> > quick succession from the same card, a timed lock is placed on a hash
>> > the
>> > card number for a number of seconds (0, 30, 60, 120, as required). No
>> > other
>> > payment can be taken on that card while the lock is in place.
>> > Our current way of implementing (2) is to insert into a table a row
>> > containing the card-hash and the expiry time of the lock. Another
>> > can overwrite the lock if the expiry has been exceeded. A periodic
>> > remover process deletes all expired locks to keep the size of the lock
>> > table
>> > small.
>> > The trouble with managing these locks in a database is that the tables
>> > getting "hot" and becoming one of the main sources of contention. Also,
>> > SQL
>> > is not necessarily fast for doing the required updates.
>> Ted Dunning, CTO