directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Pastore <>
Subject Re: Transactions on Apache Mavibot
Date Wed, 10 Feb 2016 14:51:10 GMT
Firstable thank you for the quick response, I'm happy to hear that feature
is on the table. As for the participation proposal, I really would like to
help but the truth is that I'm still a junior developer and I feel like I
still have a lot to learn, in fact it was a bit difficult for me to keep up
with the code already written in this project, so I feel that most of the
time I would be in the way instead of actually helping you guys. However,
for the time being I will try to implement the feature on my own for the
sake of learning and if I arrive to something decent (and by that time
nothing is implemented on that matter) maybe I could share it with you for
a code review if you don't mind. (Under no obligation of course). Thank you


*Roman Pastore* [image: Asante IT] <> Sarmiento
1758 ǀ 4to piso ǀ Buenos Aires ǀ Argentina
Phone: +54 11 5272 1422
Email: <> ǀ Skype:
Software Developer

2016-02-10 11:15 GMT-03:00 Emmanuel Lécharny <>:

> Le 10/02/16 14:51, Roman Pastore a écrit :
> > Hello everyone,
> > I've been using Apache Mavibot lately to see if it would fit with a
> project
> > that I have in mind. For this project I need to be able to manage the
> > transactions made in the BTree. I saw that you provided
> beginTransaction()
> > and commit() methods in the RecordManager but I'm not sure how to use
> them
> > on a tree. I saw that the insert method from the BTree already
> opens/commit
> > a transaction for every tuple inserted, but what if I want to be able to
> > open a transaction make a bunch of write operations inserts/deletes and
> > then commit so those operations are performed atomically as one (or not
> at
> > all in case of a failure), is that possible? Thank you in advance.
> >
> This is a work in progress. We are doing a complete rewrite of this part
> lately in a branch, as we need to be able, as you do, to support many
> operation within a transaction. That would not only provide some
> protection across operations, but also speed up the updates a lot (as we
> will do the modifications in memory before flushing everything during
> the commit(). A quick estimation is that the gain would be a factor 2 as
> soon as 2 updates are done in a simple transaction, and potentially more
> if more operations are to be done in one single transaction.
> So, yes, it *will* be possible, but it's not yet available. I would say
> that it's a matter of a couple of week, now I have to find those two
> weeks to work on that...
> May be you would be interested in participating in this effort ?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message