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 again.
Greetings. *Roman Pastore* [image: Asante IT] <http://www.asanteit.com/> Sarmiento 1758 ǀ 4to piso ǀ Buenos Aires ǀ Argentina Phone: +54 11 5272 1422 Email: [email protected] <[email protected]> ǀ Skype: romanpastore Software Developer 2016-02-10 11:15 GMT-03:00 Emmanuel Lécharny <[email protected]>: > 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 ? >
