[Date Prev][Date Next]
Re: LDAP transactions
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?