Hi Henry, I can appreciate your concerns about clocks, but there are no safety issues with our system. If locks are held for a few seconds too long, no-one will be concerned.
I am currently looking at moving two locking mechanisms from within a SQL database into a distributed locking mechanism of some sort. The application is a credit-card processing engine. The two locks are: 1. terminal locking - payment messages carrying terminal-ids (TIDs) are sent to acquiring banks. The acquiring systems assume that terminals are physical devices and get confused if more than one message arrives from the same TID at the same time. This is currently handled by updating a lock field in a table containing the TIDs. This was covered by my "how do I lock one-of-many" question yesterday. 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. regards, Martin On 24 February 2010 18:21, Henry Robinson <he...@cloudera.com> wrote: > A cautionary note with this problem - who says when 2 minutes is up? Clocks > will go forward at different rates and with different offsets. You cannot > rely on two machines having the same perception of what 2 minutes means. In > general, in distributed systems, it's a good design principle to minimise > any dependence on a common notion of real time. > > That said the best way is to pick some machine, like Mahadev says, to > retire > old locks by polling every N seconds, where N is the slop you can afford. > > What problem are you actually trying to solve? > > cheers, > Henry > > On 24 February 2010 03:40, Martin Waite <waite....@googlemail.com> wrote: > > > Hi, > > > > Is there a good model for implementing leases in Zookeeper ? > > > > What I want to achieve is for a client to create a lock, and for that > lock > > to disappear two minutes later - regardless of whether the client is > still > > connected to zk. Like ephemeral nodes - but with a time delay. > > > > regards, > > Martin > > > > > > -- > Henry Robinson > Software Engineer > Cloudera > 415-994-6679 >
