Bugzilla from strasser@uni-bremen.de 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-impleme... Sent from the Boost - Dev mailing list archive at Nabble.com.