Boost logo

Boost :

Subject: Re: [boost] [persistence] interface overview
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-08-23 08:54:23


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(_) {

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(;
// do something with shptr
// in a nested call to f dbptr is written
// will the use of shptr contains the modifications done by f?

----- Original Message -----
From: "Stefan Strasser" <strasser_at_[hidden]>
To: <boost_at_[hidden]>
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:
> I'd appreciate your comments.
> please note the "open issues" section.
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at