directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: txn conflict handling and tests
Date Mon, 09 Apr 2012 18:31:31 GMT
Le 4/9/12 7:51 PM, Selcuk AYA a écrit :
> On Mon, Apr 9, 2012 at 12:18 AM, Emmanuel Lécharny<>  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...)

Emmanuel Lécharny

View raw message