> >>I think if you do know in advance what the result of an operation will >> be, >>and you can speculate enough about the expected results you intend to >>handle, I think the current mech is enough. For instance, for your >>problem you could just intercept the delete in foo_op_delete, do an >>internal search (possibly as the rootdn), copy the entry if it exists and >>store it somewhere (I think I used the ldap_pvt_thread_pool_[gs]etkey to >>keep it 'round the operation); then, in case of success, in >> foo_response() >>do what you need, otherwise just delete the copy. > > Then you have two entries in the directory with the same UUID. If the > DSA crashes before the original entry is deleted then directory is > left in an inconsistent state.
No, the copy will be in memory (in the memory of the thread) so you'd likely risk to end up with none. I'm not saying this would be transactional, although I guess it could be made so, e.g. by actually writing it to an otherwise inaccessible database that would work much like a journal, and move it to the real database only when the delete actually succeeds. p. -- Pierangelo Masarati mailto:[EMAIL PROTECTED] SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
