directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selcuk AYA <>
Subject Re: Storing the txn nto each operationContext
Date Sun, 25 Dec 2011 16:58:37 GMT
On Sun, Dec 25, 2011 at 5:37 PM, Emmanuel Lecharny <> wrote:
> Hi,
> I started to play with this concept. The idea is to able to have
> encapsulated operations using their own transactions, following these rules
> :
> 1) if there is another pending Read transaction, and if the new operation is
> read only, then reuse the pending transaction
> 2) if there is another pending Read transaction, and if the new operation is
> ReadWrite, then create a new transaction
> 3) if there is another ReadWrite transaction, then generate an error (we
> can't have such a case)
> That means we can have a non limited number of encapsulated RO txns, but we
> can't have more than one RW txn running.
> RO(RO(RO...(RO)...))) is possible
> RO(RO(RW))) is possible
> RO(RO(RW(RO is not possible
> RW(RO is not possible
> RW(RW is not possible
> In order to implement that, we need to add one thing :
> - a nbRef in readOnly transactions, which will be incremented and
> decremented as soon as we add new RO txns or abort/commit txns
> Is that enough ?

this is also a reply to you previous email.

I suggest we use a txn per operation but we do not have to store the
txn context pointer in operation context. We can still have the thread
context stored in thread local variable but we also store a TxnHandle
ref in EntryFilteringCursor. And we do something like this:

  get txn handle stored in the cursor and set it as the thread local variable.
do the next
unset the thread local variable.

Lets say an embedded app developer does something like this:

open cursor1

while ( next on cursor1 ).
  for some certain entry do a delete

open cursor2
do a search on cursor2.

close cursor1
close cursor2


if we do something like suggested above, then consistency semantics is
clear: each cursor sees the world as of the time it is opened. So
cursor1 does not get affected by the delete and cursor2 sees the
delete. This implementation does not use txn reuse.

If we deal with reusing the txn contexts and hence ref counts,
depending on where you close the cursor, what cursor2 see will change.
As I understand your suggestion, in the above scenario, delete uses
its own txn and cursor2 reuses cursor1's txn. So cursor2 wont see the
delete as it see the world as of cursor1's opening time. But if
cursor1 is closed before opening the cursor2, then cursor2 will see
the delete. For a developer,  such things make reasoning with
consistency  I think.

> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny

View raw message