Postgres Store and locking issues

[Robin H. Johnson]

Hi all,

So firstly, as of r1080, the Postgres store is now in SVN.
I'd say use it for your testing now, but don't rush to deploy it to
production, the locking stuff will most probably be changing soon.
If you DO want to use it and something crashes, keep your eyes open for
stale locks that you'll have to clear by hand.

Locking in MogileFS
-------------------
As of writing this, MogileFS uses locks in two specific places.
1. To atomically update the devcount column of the file table;
   This lock is named mgfs:fid:$fidid.
2. To ensure each FID is replicating to only one destination at a time;
   This lock is named mgfs:fid:$fidid:replicate.

The MySQL store uses GET_LOCK($lockname, $timeout) and
RELEASE_LOCK($lockname).

MySQL's GET_LOCK provides the following properties:
1. A client may only hold one lock at a time.
2. The lock is automatically released when the client disconnects.
3. All locks (regardless of origin) exist in a single global namespace.

#3 is critical for functionality.
#2 is important because it saves on stale lock cleanup.

In the Postgres store, I found that the
pg_try_advisory_lock/pg_advisory_unlock functions that Postgresql
provides are not suitable to emulate the GET_LOCK behavior.

Instead, I implement a 'lock' table, consisting of a lockid (hash of the
lockname), hostid, pid and a timestamp.
This provides the global namespace (#3), and optionally allows, but does
not impose the single lock (#1) limitation.
HOWEVER, it does not have any form of automatic cleanup.

I had intended to have an additional lock (with a unique ID of the
machine+port) per tracker, and if the tracker started and saw the lock
was already held but the machine+port was free, it knew it could clean
up all locks with that host, and additionally, if a worker process
crashed, the tracker would be aware of it and could expire it's lock.

Bradfitz however has proposed an alternative: 
ddlockd	http://code.sixapart.com/svn/ddlockd/trunk/
This seems much saner to me, and it also means that other Store
implementations won't have to bump into the lock problem.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail     : robbat2 at gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 321 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/mogilefs/attachments/20070626/9bd6891a/attachment.pgp