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
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
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.
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
> old locks by polling every N seconds, where N is the slop you can afford.
> What problem are you actually trying to solve?
> 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
> > to disappear two minutes later - regardless of whether the client is
> > connected to zk. Like ephemeral nodes - but with a time delay.
> > regards,
> > Martin
> Henry Robinson
> Software Engineer