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 05:18:26

Bugzilla from strasser_at_[hidden] wrote:
> 
> 
> Am Tuesday 11 August 2009 11:05:28 schrieb Vicente Botet Escriba:
>>
>> I have some questions:
>> When the serializable object is saved/loaded to/from the disk?
> 
> that's an implementation detail, an object can be saved and removed from 
> memory at any time, as soon as the library user doesn't use it
> anymore(i.e. 
> holding a shared_ptr to it)
> the prototype currently uses boost::weak_ptr to refer to an object and
> saves 
> on object destruction, with a very simlpe caching mechanism in place to
> avoid 
> objects constantly being loaded and saved. see cache.hpp
> 
>> Can we have persistent object without transactions on your library?
> 
> objects can be read outside of a transaction. the prototype doesn't allow 
> writing outside of transactions.
> although that would be possible, it requires a lot of effort (esp. with
> regard 
> to reference counting) and I don't see the benefit.
> there is no limit to the size of a transaction, so you could begin a 
> transaction at application startup and commit at shutdown, if you don't
> want 
> to bother with transactions.
> 
> 
Does this means that a persistent object is writen to disk only when a
db_ptr is reachable while commiting a transaction?

> 
>> Ok, I see that the files are not an implementation detail, and that your
>> are really looking for persistence.
> 
> 
> the way I see it now is that the libraries have 2 very different goals,
> with 
> transactional memory being a requirement for reaching the goal
> persistence.
> so once BoostSTM is part of boost, the transactional part of persistence
> could 
> be reimplemented to use BoostSTM and possibly improve performance over the  
> current object cloning mechanism used.
> do you agree with that?
> 
> 
 BoostSTM has not made with persistence in mind. I think we need some deep
redesign (separating what is related to the transaction and what is related
to the storage, either persistent or not) to allow this. 

> 
> 
>> the wrapper of global_int is tx_global_int. The question is if global_int
>> must inherit from transactional_object or not. Up to now it works only
>> for
>> objects inheriting from transactional_object (which is the more
>> efficient),
>> but we are working on removing this constraint (which will be less
>> efficient because the transactional information need to be looked up from
>> a
>> cache map).
> 
> I took a short look at transactional_object.
> 1.
> it seems it's there to store some object-specific information. why don't
> you 
> wrap that around the object instead of deriving from it?
> that wouldn't hide it completely from the user, but at least it would be 
> non-intrusive to user types, without affecting performance.
> 
> e.g.
> template<class T>
> struct transaction_object{
> 	T user_object;
> 	//object-specific info
> };
> //user-space:
> transaction_object  a;
> 
> and your smart pointers would "dereference" the transaction_objcet to T.
> 
> or:
> template<class T>
> struct transaction_object : T{
> 	//object-specific-info
> };
> 
> I use the first approach, see object_instance<> in object.hpp.
> 
> 
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.
native_trans<T> wraps already any arithmetic builting type, but the
interface is fixed and known.

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

Best,
Vicente

-- 
View this message in context: http://www.nabble.com/persistence-library-proposal-%28with-prototype-implementation%29-tp24819447p24931885.html
Sent from the Boost - Dev mailing list archive at Nabble.com.