LMDB KDB module design notes

[Greg Hudson]

On 04/15/2018 04:51 PM, Nathaniel McCallum wrote:
> On Thu, Apr 12, 2018 at 12:34 PM, Greg Hudson <ghudson at mit.edu> wrote:
>> On 04/12/2018 11:56 AM, Simo Sorce wrote:
>>>> Transactions are per-environment, so if we use one database file and a
>>>> write transaction for loads, loads would block the KDC.  That's worse
>>>> than what we have with DB2.
> 
> Could loads be segmented into chunks to avoid blocking the KDC for the
> entire operation?

I don't believe so.  If loads were purely additive, sure, but they also
delete the entries not present in the file.

> Could you create an opportunistic write queue for these ? This would
> unblock the KDC during loads. The cost would be that the
> aforementioned writes would not occur until the ends of the loads.
> Slightly stale data is probably not a big deal for (at least)
> last_success.

I would like to see an objection more substantial than "I don't like
having multiple DB files" before thinking about adding something as
complicated as a KDC database write queue.  We've been living with
multiple DB files in the DB2 back end (for principals and policies) for
the lifetime of the project.