[Date Prev][Date Next]
Re: Move SLAPI in an overlay...
>I had some need of the kind with back-sql, and I implemented a specific
>layer that allows to rewrite the DN outside of its string representation
>to comply with SQL odds. A general interface could be interesting, but I
>fear the impact on performances; it should be totally transparent if not
>required, much like overlays right now.
I think we could have a transparent DB overlay layer. Backends that
wished to participate would divide their add, delete, modify and modify
RDN operations into an "upper" and "lower" half (using "front" and "back"
is a bit confusing).
The upper half would begin the enclosing transaction for the operation,
and (if it exists) retrieve and lock the entry which is the target of
the operation. It would then call the lower half through the backend
(or frontendDB if global DB overlays were to be supported).
For example, the add operation might look like:
Begin outer transaction
Get existing entry
Commit outer transaction
if (Entry already exists)
Begin inner Transaction
Add entry to DB, indices, etc
Commit inner transaction
For modifies, the lower half could essentially be bdb_modify_internal().
If the overlay layer also exposed generic transaction primitives,
then Simple Transactions could be implemented in a DB-independent
overlay. (But this is probably moot given that back-bdb/back-hdb
are the only backends likely to support them.)
Our requirements essentially boil down to:
o access to a locked entry snapshot on add/modify (for
updating per-entry metadata, for example) (the seqmod overlay
could give us a moral equivalent)
o atomic processing of modify and modify RDN operations (we
could do this with Simple Transactions were they implemented)