Hi, in the documentation you say, "Objects can be read outside of transactions, but no object can be created or changed outside of transactions. " So how do you manage with conflicts between reads outside transactions and writes inside transactions? Maybe you can clarify this on the documentation. As db_ptr is a shared_ptr why not name it shared_db_ptr (note that you have already a weak_db_ptr) or even better, why don't name them shared_ptr and weak_ptr but on the namespace db? Do you think that it will be possible to manage db pointers that are not managed, so it will be up to the user to create/remove them explicitly? About commit_transaction, in TBoost.STM we have defined a macro atomic so you can do the following atomic(_) { book->friends.push_back(...); } Of course the corrct boost name will be BOOST_STM_ATOMIC. Maybe you can take a look at this macro. It avoids to force defining a specific function and pass it as parameter to the commit_transaction function. Related to "Improving performance", what hapens if in a transaction we access a db_ptr using the read function, then we modify it in a neested function/transaction and then we re-read this shared_ptr. Will the readen pointer corresponds to the written one? transaction tx; shared_ptr<T> shptr(dbptr.read()); // do something with shptr // in a nested call to f dbptr is written f(); // will the use of shptr contains the modifications done by f? ----- Original Message ----- From: "Stefan Strasser" <strasser@uni-bremen.de> To: <boost@lists.boost.org> Sent: Sunday, August 23, 2009 12:53 PM Subject: [boost] [persistence] interface overview
A while ago, I proposed a persistence library and there was some interest.
Since then, the prototype has evolved into a feature-complete, reasonably optimized, implementation. Here's a quick recap of what the library is supposed to do:
--------- int main(){ ... shared_ptr<A> shared(new A); db_ptr<A> db(new A); ... } // "shared" is destroyed, "db" is saved to disk
to ensure data consistency, there are transactions introduced:
transaction tx; //change_objects tx.commit();
if change_objects throws an exception, causing tx to be destroyed without commit() being called, all changes are undone. ---------
there is no complete documentation yet, but I've written an overview of the library interface, which can be found here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=overview.html&directory=persistence&
I'd appreciate your comments. please note the "open issues" section. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost