[Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited)

[Jeff Johnson]

While slowly absorbing sks-keyserver code by browsing mail archives and code,
I found this attempt to add DB_INIT_LOCK way back when:

        http://lists.gnu.org/archive/html/sks-devel/2004-07/msg00018.html

So I added DB_INIT_LOCK, restarted servers, and verified
        Yup, deadlock still exists, broken.

(aside)
Well, half broken: the KDB, but not the PTree, database seems okay
with DB_INIT_LOCK.

The fundamental issue (imho) is that Berkeley DB does locks per page, not
locks per record, and so its pretty easy to self-deadlock.

Running db_deadlock (as attempted in the link above) is one approach.

But there are other approaches as well, including
        1) reducing page size to one key per page
        2) changing the access to avoid the READ <-> WRITE deadlock
        by postponing the writes until after the reads are finished
and perhaps several other means.

(aside)
BTW, can someone describe -- even superficially -- what is
being attempted with the PTree store? Any details are welcomed,
I'm not yet able to read OCAML code well enough to recognize
what type of store is being attempted.

The PTree deadlock is easily reproduced, and (with db_stat) a
detailed deadlock diagnosis could be attempted.

Is there interest in adding DB_INIT_LOCK to the PTree store?

Has anyone else looked at DB_INIT_LOCK since the link in the archives above?

Any historical context is appreciated.

73 de Jeff