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
