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
