directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <>
Subject Re: How do we handle recursive requests wrt transactions ?
Date Wed, 21 Dec 2011 06:13:58 GMT
Since you cannot use triggers right now, I am assuming you are trying
to do the recursive delete thorugh ldap core connection?

As I tried to explain in my previous emails, the first thing to decide
is to where to put the transaction boundaries:

* For Ldap requests over the wite, ldap protocol handlers insert the
txn boundaries.
* For ldap core connection, it seems you guys discussed and wanted to
put txn boundary per request and want to close the txn when cursor is

when discussing with Emmanuel, I remember clearly that user should be
aware that LDAP is not transactional and users should be aware of it.
So if you are doing a recursive delete through ldap core connection
and transaction boundaries are per request, then you should know that
the whole thing is not a txn itself.

That said, if you insert txn boundaries per request, then you need to
deal with a couple of things:

* Handle txn commit, abort for search. As mentioned in previous
emails, this can be done in cursor close.
*When a search cursor is open, another search cursor can be opened.
*When a search cursor is open, a delete/add/modify request might be made.

If txn boundary is per request, then you have two options to handle the above:
* Introduce txn ref count and close the txn context when the ref count
drops to zero. This is similar to nested txns concept and if a nested
txn aborts, the final enclosing txn aborts.
* When a cursor is open and a delete/add/modify is made, read only txn
has to be upgraded to read write txn. When the final enclosing txn
commits, it can get a conlfict exception and the whole request has to
be repeated.

So, although we try to hide the txns from the user, the above approach
is clearly not intuitive for the user as final cursor close determines
txn boundary and txn has to be retried after a conflict exception.

We have two options:
* Have a txn context per request. Store context with cursor, then when
user switches into cursor, restore its context, when it is leaving
cursor, remove txn context. This way you dont have to deal with txn
ref count or txn upgrade. I did something like this with jdbm browsers
so that implementation there was totally hidden from the upper layers.

*In embedded case, leave it to the user to determine the txn
boundaries. This way things like recursive delete thorugh ldap core
connection would meaningfully work .

Last and not least, since more than one person is involved in the code
now, please let us know what you plan to do before you do any anything
about code. Many of the points above were discussed here and there but
I did not see a clear decision made about them, at least in the


On Wed, Dec 21, 2011 at 2:33 AM, Emmanuel Lecharny <> wrote:
> Hi,
> I tried to get some tests passing where a recursive delete is done. The
> problem is that we do a search at each level, whch means we start a new
> transaction at each new level.
> I can easily check that a transaction has not been started yet (so that the
> txn is only started once), but as I try to commit the txn when the cursor is
> closed, I have a problem to close the right txn (ie, the one that has been
> started in the outer loop).
> Any idea on how to get it working ?
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

View raw message