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 >
