Re: LDAP transactions

[Ralf Haferkamp <rhafer@suse.de>]

On Donnerstag, 24. April 2008, Howard Chu wrote:
[..]
>
> It's tempting to think about this for backglue, but we'd need a
> cross-database lock manager of some kind for detecting deadlocks.
> That implies that we really need an LDAP-level lock request, to
> handle distributed locking, and that the Transaction handling ought
> to be built on top of that. Currently the Transaction layer says
> nothing at all about locking, and it's up to the underying LDAP
> database to take care of it.
It's not only tempting for backglue, I guess. It's also interesting for 
other multiple database setups. E.g. the setup that Samba4 uses 
currently. If I understand you correctly, slapo-memberof and -refint 
could be implemented to (optionally) work transaction based  across 
multiple databases then.
On the other hand, ignoring the multiple database setup for transactions 
for now seems to be quite a lot easier to implement and might the a 
good thing to do as a first step to see where we can go from there. 
Though I am probably overestimating the amount of work needed to get 
transactions working in a backglue config. 

> I guess another approach would just be to have backglue fully
> serialize all transactions; if only one is outstanding at any time
> there can be no deadlocks.
>
> This brings up a question about whether slapd in general should fully
> serialize them. I was thinking, at the least, that we should only
> allow one active transaction per connection,
I guess you mean LDAP-level transactions here, not transactions on the 
backenddb-level? Yeah, I guess that's ok. AFAIK it's even already a 
restriction of the current (partly) implementation in HEAD.

> though that was mainly a 
> matter of convenience. Thoughts?

-- 
Ralf