Boost logo

Boost :

Subject: Re: [boost] [persistence] interface overview
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-08-23 11:58:02

Am Sunday 23 August 2009 14:54:23 schrieb vicente.botet:

> 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.

a read outside of a transaction returns the committed state of that object at
the time. (consistent state within the object.)
if you need an atomic read across more than one object, you can use a

> 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?

db_ptr is not a shared_ptr, think of it more like an "object id". it does not
keep the referenced object in memory, see pitfalls -> object lifetime for
the name "db_ptr" is certainly imperfect and might depend on if the whole
library stays with its name (robert ramey suggested a name change). the
namespace currently is persistence.

> 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?

I'm not sure if I understand that question you mean objects
that are not reference counted and must be added and removed explicitely?

> About commit_transaction, in TBoost.STM we have defined a macro atomic so
> you can do the following
> atomic(_) {
> book->friends.push_back(...);
> }

thanks, I did look at it. how is the catch-block added?
do you have to use another define after {}?

though you could stop commit() from throwing and just let it return false to
indicate that the transaction failed and avoid a catch block.
I need to think that through though because not only commit() can throw
isolation_exception, it can be thrown much earlier.

but your macros still have a "try" at the end, I wonder what that's for?

> 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?

no. that is addressed in the documentation in pitfalls->transaction
boundaries. maybe one could describe that more clearly and prominently in the
final documentation.
so objects should always be accessed through their db_ptr's.

thanks for your comments. which version of the db_ptr interface do you prefer?
(at the end of overview.html)

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