sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] sks-peer.spodhuis.org catching back up


From: Jeffrey Johnson
Subject: Re: [Sks-devel] sks-peer.spodhuis.org catching back up
Date: Tue, 29 May 2012 17:20:43 -0400

On May 29, 2012, at 2:20 PM, Jeffrey Johnson wrote:

> 
> On May 29, 2012, at 1:49 PM, Phil Pennock wrote:
> 
>> Kristian drew my attention to sks.spodhuis.org showing a last update of
>> May 25th.
>> 
>> I'd tried to make sksclient be read-only in BDB access, but failed to
>> find a way to do so because a directory-based BDB *always* seems to use
>> log files.  So I'd given up and gone with the flow.
>> 
> 
> Sure there's a way to use Berkeley DB without transactional logs.
> 
> FWIW, what is actually implemented in the SKS key servers isn't fully ACID:
> I can dig out details if anyone really cares. I looked a bit at extending the
> implementation to be fully ACID, but stopped because of the difficulty in
> identifying the records being retrieved because OCAML isn't my favorite 
> language.
> 

Since we are here … there are two dbenv's in use by SKS key servers
with shared/interlocked state. ACID behavior is meaningless when there are 2
dbenv's in use: each database has its own transaction log but there is no 
enforcement
of ACID behavior between the 2 databases with different dbenv's other
than time coincidence.

There's a couple of more detailed implementation details needed: meanwhile,
I suspect that there are so many "Berkeley DB Haters" around that a simpler
concurrent access model using DB_INIT_CDB might be the better choice for
SKS key serves (assuming there isn't write starvation from shared readers 
blocking
timely exclusive writes).

73 de Jeff




reply via email to

[Prev in Thread] Current Thread [Next in Thread]