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
