Re: Move SLAPI in an overlay...

[Luke Howard <lukeh@padl.com>]

>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:

	db_add_upper()
	{
		Begin outer transaction
		Get existing entry
		Call be->add_lower()
		Commit outer transaction
	}

	db_add_lower()
	{
		if (Entry already exists)
			Return error
		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)

-- Luke

--