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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk