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 closed. 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 emails. regards Selcuk On Wed, Dec 21, 2011 at 2:33 AM, Emmanuel Lecharny <[email protected]> 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 > www.iktek.com >
