Le 4/9/12 7:51 PM, Selcuk AYA a écrit :
On Mon, Apr 9, 2012 at 12:18 AM, Emmanuel Lécharny<[email protected]> wrote:
Le 4/8/12 8:55 PM, Selcuk AYA a écrit :
Hi,
Hi !
I have finally checked in the tests fixes for handling txn conflicts.
I added some test and they are passing but I am having some problems
with the test framework. First a summary of how txn conclicts are
handled and why the tests are kind of important.
Txn conclicts detection and handling deals with cases which would
normally be handled by locks. When a RW txn tries to commit and it
detects a conflict, it aborts and retries. In order to be able to
retry, each operation context saves itself before being executed and
is reset based on the saved information if txn aborts because of a
conflict and needs to retry. For example and add operation context
saves the original entry it wants to add and a modification context
saves the original list of modifications it needs to apply.
FYI, the original entry is always read and stored in the OperationContext
when the operation is received. This is done by the eagerlyPopulateFields()
method in DefaultOperationManager. If the OperationContext is kept in memory
until the operation is fulflled (even if you have to rollback it because a
RW txn has failed), then you have the original entry available.
am aware of that. Original entry has to be reread in eagerlyPopulate
fields when txn is retried because txn has a different start time when
it is retried and it will see a different world.
Ah, yes. The entry have been modified, so we must reread it. Make sense...
Just one thing : we could probably bypass the complete chain as the
entry's UUID will not change, and we will grab the entry from teh cache
directly (thinking out loud here...)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
