directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Txn discussion
Date Sat, 09 Jun 2012 15:22:41 GMT
Hi guys,

independently from the ongoing work on the txn layer, I'd like to start 
a thread of discussion about the path we selected, and the other 
possible options.

Feel free to express your opinion here, I'll create a few items I'd liek 
to see debated.

1) Introduction

We badly need to have a consistent system. The fact is that the current 
trunk - and I guess this is true for all the released we have done so 
far) suffers from some serious issue when multiple modifications are 
done during searches. The reason is that we depend on a BTree 
implementation that exposes a data structure directly reading the pages 
containing the data, expecting those pages to remain unchanged in the 
ong run. Obviously, when we browse more than one entry, we are likely to 
see a modification changing the data...

2) txn layer

There are a few way to get this problem solved :
- we can have a MVCC backend, and a protection against concurrent 
modifications. Any read will always succeed, as each read will use a 
revision and only one.
- we can also read fast the results and store them somwhere, blocking 
the modification until the read is finished.
- or we can keep a copy of the modified elements within the original 
elements, until the seraches that use those elements are finished.

(there are probably some other solutions, but I don't know them)

AFAICT, the transaction branch is implementing the third solution, 
keepong the copy of modified elements in memory, so that they can be 
sent back to the user.

None of those solution are free of drawbacks.

I think that the first approach, even if it implies we forces a 
serialization of the writes, is the best solution. The rational, AFAICT, 
is that we don't have to deal with the way the backend keep versions of 
elements, this is not our business. Plus keeping the write serialized 
guarantees that we won't compromized the backend.

At this point, I'd like we discuss all those options, whatever we are 
currently working on.

3) cross-partition vs single partition protection

Atm, we are working on a cross partition system. That means we protect 
all the partitions at the same time : moving an entry from one partition 
to another one will be done completely, or reverted.

I'm not sure we need such a feature. I don't see what it brings, and 
even if it brings some advantages, I'm not sure we need such a feature now.

Not having to add a txn layer above the partitions is way easier to 

Here, too, I'd like we discuss our options, and the pros and cons of 
using a txn layer on top of single partitions instead of
muliple partitions.

ok, this is probably enough elements we have to discuss. You turn :)

Emmanuel L├ęcharny

View raw message