LMDB KDB module design notes

Greg Hudson ghudson at mit.edu
Sun Apr 15 17:43:28 EDT 2018

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.

More information about the krbdev mailing list