LMDB KDB module design notes

[Simo Sorce]

On Thu, 2018-04-12 at 10:59 -0400, Greg Hudson wrote:
> On 04/12/2018 08:03 AM, Simo Sorce wrote:
> > >   The lockout environment is never emptied, never iterated over, and
> > >   uses only short-lived transactions, so the KDC is never blocked more
> > >   than briefly.
> > 
> > I am not a fan of setups that use multiple files for databases, especially when
> > transactions need to span multiple ones.
> > What is the underlying reason to do this in the new design instead of using a
> > single database file with all the data ?
> 
> 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.
> 
> Alternatively we could load into a temporary database file and rename it
> into place like we do with DB2.  But we would then have to close and
> reopen the database between operations like we do with DB2, or somehow
> signal processes that have the database open to reopen it after a load
> completes.

How common are loads ?
As far as I know LMDB will let you keep reading during a transaction, so
the KDC would block only if there are write operations, but won't block
in general, right ?

The only write operations are on AS requests, when lockout are enabled
and when that triggers a change in the lockout fields. How common is that ?
Would that something that can be mitigated by deferring those writes during
transactions ?

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc