Boost logo

Boost :

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);

Now the update of member will be taken in account by the transaction tx.


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at