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
in "FN".

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
excessive ?


On 25 February 2010 08:07, Martin Waite <waite....@googlemail.com> wrote:

> Hi
> 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.
> regards,
> Martin
> 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
>> cards
>> in a single file.
>> On Wed, Feb 24, 2010 at 11:10 AM, Martin Waite <waite....@googlemail.com
>> >wrote:
>> >   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
>> of
>> > 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
>> process
>> > can overwrite the lock if the expiry has been exceeded.  A periodic
>> garbage
>> > 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
>> are
>> > 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
>> DeepDyve

Reply via email to