On 12/21/11 6:36 PM, Selcuk AYA wrote:
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 .
Now, I'm thinking that option 1 is probably better. All in all, if some user
of our server (not embedded) is doing a recursive search, we have to
guarantee that it will work, whatever add/delete/modify he does in the
middle, and without exposing the txns. In embedded mode, we should do the
same thing, IMO. If it works for server-integ, it should also work for
core-integ.
I agree that option 1 is better and what the user experiences will be
the same with what he experiences through ldap request handlers.
One thing that might make life easier is if we do this thing at
CoreSession layer. I originally was against this as layers above
CoreSession might want to group requests into txns. However we can
still allow the layers above CoreSession group multiple requests into
a txn by checking if txn is already enabled at CoreSession layer.
Overall, this might decrease the number of changes.
Now that I have cleaned up my environment by committing some side
modifications I had, I can start experimenting this approach.
Note that the errors I get with the latest revision of your branch are
the exact same than the one you exposed in your mail last week.
I'll keep working on this code until friday, FYI.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
