Bugzilla from strasser@uni-bremen.de wrote:
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.
Again, you are right, the smart pointer can return a pointer to the instance T wrapped.
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; }
Neither A nor B are errors. In both cases the modification is done on a non-transactional bases, even if done on the context of a transaction. The STM system has no means to know whether an access to a given variable is modifying it or not.
A and B imho should behave in the same way when used as a transaction object.
We need to say to the STM system that some data participates on a transaction. The question is if we require that a type must be able to be used on a non transactional context and on a transactional context. In this case the type should not Note that transactional objects can not be embedded as the BoostSTM is object based and the backup will overlap. The code we could write could be something like struct B{ void do(){ *a=1; } tx_ptr<int> a; }; and define the operator* on tx_ptr as including the object on the transactional cache and returning the reference to this catch. This has syntactical advantages, but performance disadvantages. I will explore a little more this possibility.
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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Best, Vicente -- View this message in context: http://www.nabble.com/persistence-library-proposal-%28with-prototype-impleme... Sent from the Boost - Dev mailing list archive at Nabble.com.