Boost logo

Boost :

Subject: Re: [boost] persistence library proposal ( with prototypeimplementation )
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-08-12 09:31:39

Am Wednesday 12 August 2009 11:18:26 schrieb Vicente Botet Escriba:
> Does this means that a persistent object is writen to disk only when a
> db_ptr is reachable while commiting a transaction?

yes. an object only survives a transaction if it is reachable from the
database root.
see the banking example. there the bank is the database root, and it hold's
db_ptr's to the individual accounts, so the accounts are reachable and saved
to disk.
just like you'd expect from a boost::shared_ptr.

> The wrapper has the drawback that doesn't define the same interface as the
> type T. So when the smart pointer is dereferenced the result will not
> provides these interface.

why not? the smart pointer would either return a int & or an int const &,
depending on read or write access.

> > 2.
> > I noticed that in transaction_object, you call the user-supplied
> > operator= of
> > T, accomplishing only a shallow copy of the object.
> > does that mean that:
> >
> > struct A : transaction_object {
> > B *b;
> > };
> >
> > A a;
> >
> > write(a)->b->member++; //non-transactional memory?
> Whether member is transactional or not depend on whether B inherits from
> transactional_object < B > or not. Anyway you are right, you need to access
> the member b using a transactional smart pointer
> wr_ptr< B > tx_a_b(a.b, tx);
> tx_a_b->member++;
> Now the update of member will be taken in account by the transaction tx.

I'd reconsider that.

struct A{
        void do(){ a=1; }
        int a;
struct B{
        void do(){ *a=1; } //error
        int *a;

A and B imho should behave in the same way when used as a transaction object.

If you disagree with that, or if that's impractical for some reason, there is
really no point in removing the requirement to derive from
the implementor of the type must be very aware that he's implementing a
transaction object anyway, so I'd consider it not a bug but a feature, that
he must express this intention explicitely by deriving from

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