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

Subject: Re: [boost] persistence library proposal ( with prototypeimplementation )
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-08-11 11:42:15

Am Tuesday 11 August 2009 01:03:32 schrieb Ilya Bobir:
> Thought unless you track individual fields you will have to load objects
>   as a whole.  And you will probably have to write your own
> serialization layer as the boost::serialization library will not allow
> you to do this kind of optimizations.

I don't see a problem here. I implemented a similar (more complex) library 
for .NET, and there the limiting factor was harddrive speed.
obviously, with reflection and a just-in-time-compiler you can generate 
serialization code at runtime which improves performance, but I certainly 
wouldn't want to ditch boost.serialization for a little better performance. 
runtime code generation isn't practical in C++ anyway.

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.

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

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

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<A>{
        B *b;
};

A a;

write(a)->b->member++; //non-transactional memory?