directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
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<elecharny@gmail.com>  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


Mime
View raw message