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 cards
> 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