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?