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.