Re: [boost] [persistence] interface overview

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.

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

>
> 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 
that.
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 correctly...do 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)