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?