Re: [boost] persistence library proposal ( with prototypeimplementation )

Subject: Re: [boost] persistence library proposal ( with prototypeimplementation )
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2009-08-12 11:12:05

Bugzilla from strasser_at_[hidden] 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-implementation%29-tp24819447p24938660.html
Sent from the Boost - Dev mailing list archive at Nabble.com.