On 10/5/11 2:38 PM, Selcuk AYA wrote:
> <snip/>
> You didn't introduced the term 'transaction' before. I assume it covers
> every LDAP operation doing a modification, excluding search requests or
> lookups.
>
> it includes search as well. Search will be a transaction with MVCC
> consistency guarantee.
ok.
>
>> When you write "we will keep the DN set that the Txn touched", we need to be
>> a bit more specific : what about MODDN operations that move potentially
>> millions of entries ? Do we keep the original and modified DNs only, or will
>> we store all the moved entry's DN ? (I guess not, otherwise the system will
>> simply not scale)
> Say we move dn1 to dn2. We will keep dn1.* and dn2.* as the set of
> changed dns. So if another txn tries to modify entry with dn1.dn3,
> then it will conflict with dn1.*.
>
> That said, we might have a problem if a modification changes huge
> number of indices. This is because I am planning to keep the changes
> to the indices in the unflushed part of the WAL logs to make forward
> merge with the logs easier. MODDN is the operation that might
> currently cause this problem because it updates the sublevel index.

We discussed this aspect, and it may be a good idea to get rid of the 
sublevel index (see the other thread about it).

Using the RDN index will mitigate this issue.
>
>>>> *when a txn commits, its intention log is appended to the loggin
>>>> subsystem.
>> What is the 'loggin subsystem' ? How does it differ from the intention log,
>> except that may be the loggin subsystem is stored on disk ?
> Logging subsystem is the Write Ahead Log.

Ok. FYI, we already have 2 logs :
- changeLog, storing all the modifications and the revert operations
- journal which stores the same modification without revert operation 
for a disaster recovery system

We may want to merge all those logs into one single log...
>
>> If so, I have a Q. Suppose we have 2 txns on the same entry, T1 and T2. T1
>> is executed before T2. Suppose also that T1 takes longer to process than T2,
>> and that T2 will try to commit the txn : at step 4, we now will check if
>> another txn isn't already trying to modify the same entry, and as T1 has
>> been started before, we will get a failure. Fine. But then, why can't we
>> check that when T2 is submitted and injected in intention log (step 2) ?
> actually who fails is determined by commit time. So the execution
> history you describe is like this:
>
> T1 starts, T2 starts,...., T2 tries to commit, T1 tries to commit
>
>
> assuming no other txn tried to commit, then T2 would commit in this
> case and T1 would be rejected.
>
> There would be ways to detect the conflict early but detecting the
> conflict at commit time works.

Ok.

Thanks for the clarification Selcuk.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com