Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>
From: =?UTF-8?Q?Emmanuel_L=c3=a9charny?= <elecharny@gmail.com>
Subject: [Mavibot] ApacheCon discussions
Message-ID: <560F7313.6000101@gmail.com>
Date: Sat, 3 Oct 2015 08:17:55 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi guys,

we had some interesting discussion with Kiran and Shawn during the
Apache Conference this week. We spent some time on Mavibot and here are
a few thoughts we had about it :

- We should not have a support of multiple^values in Mavibot. This makes
the code too complex to handle, and this could be done at a upper level
(like what we have for JDBM). At the end, Mavibot should only be a
strict Key/Value store
- We don't need to have two flavor of BTrees (Persisted and InMemory).
This is the Manager role : we can have a PersistedManager and a
InMemoryManager
- The transaction support has been lenghtly discussed, and we think we
have a valid specification for it :
    - hat we need to explicitely start and terminate a transaction,
instead of have an implicit start (as we currently have)
    - we need a WorkingMemory to hold modified pages
    - as we are going to modify pages instead of copying them, we need a
different implementation fo the very basic B-tree insert/remove
operations for this case
    - revisions will be cross-btrees, and actually will reflect the
transaction manager revision, so we may have holes in teh numbering for
a goven btree
    - managing versions will be done using a list with no lock
- Cleaning up the pages can be done at teh end of an update, by what we
now call the Recycler. We can clean old revisions, starting by the
oldest and up the list, until we meet a revision which is in use. We can
also cleanup not use revisions, at least for the pages that have been
copied in the revision immediately upper.
- Last, not least, we discussed about the fact that we may have two
threads to manage updates and recycling : the contention will be minimal
and teh gain can be hudge, as we won't anymore have to process with the
cleaning after the update is completed.

I'll come with some more complete explaination and document on those
specification when back home.

I have created a branch to paly with those ideas :
mavibot/branches/single-value. This branch is where we are going to
experiment.

Thanks !