[19754] in Kerberos_V5_Development
Re: LMDB KDB module design notes
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Apr 15 17:43:46 2018
To: Nathaniel McCallum <npmccallum@redhat.com>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <56d8adb6-3e7b-be12-7e83-a1922a34937c@mit.edu>
Date: Sun, 15 Apr 2018 17:43:28 -0400
MIME-Version: 1.0
In-Reply-To: <CAOASepPYOzr3UC=z7b9Cgi9=usnrx0a6rppERj-paLE8DaCFLA@mail.gmail.com>
Content-Language: en-US
Cc: krbdev <krbdev@mit.edu>, Simo Sorce <simo@redhat.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 04/15/2018 04:51 PM, Nathaniel McCallum wrote:
> On Thu, Apr 12, 2018 at 12:34 PM, Greg Hudson <ghudson@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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
