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-11 05:05:28

Bugzilla from strasser_at_[hidden] wrote:
> 
> Am Monday 10 August 2009 10:44:42 schrieb Vicente Botet Escriba:
>> Please could you resume which are the main goals of the library?
> 
> the main goal is to be able to extend the lifetime of an object, simply by 
> using another smart pointer:
> 
> int main(){
> 	shared_ptr  shared(new A);
> 	db_ptr  db(new A);
> 	...
> } // "shared" is destroyed, "db" is saved to disk
> (given that it is referenced somewhere)
> 
> I should have explained this more clearly in my first mail, before going
> into 
> transaction details, but atomic transactions are an essential part of this 
> kind of transparent persistence, because you don't want to end up with 
> corrupted objects on disk.
> 
> 
I have some questions:
When the serializable object is saved/loaded to/from the disk?
Can we have persistent object without transactions on your library?
Does this depends on whether the smart pointer is created on a transactional
context?

> 
>> Why do you need to use files to track the memory changes, why don't just
>> memory?
> 
> the library is supposed to recover the database from application crashes.
> to accomplish this, object instances and a transaction log must be saved
> to 
> disk, even if all objects in use are cached in memory.
> see e.g. http://en.wikipedia.org/wiki/Redo_log
> 
> 
Ok, I see that the files are not an implementation detail, and that your are
really looking for persistence.

I would like a transactional system that is able to manage with object in
memory and object in a persistent storage. I need to think much more on
that.

> 
>> we are working on allowing the global_int to be declared just as an int,
>> i.e. no need to inherit from a transactional object to participate in a
>> transaction. Other improvements will concern the definition of any
>> operator
>> and the implicit conversion so we can write
>>
>>        tx_global_int++;
>>        return tx_global_int;
> 
> how do you track changes of tx_global_int without any wrapper?
> (or did you refer to two different solutions, a) declaring as an int, or
> b) 
> defining operators for an int-wrapper?)
> 
> 
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). 

> 
>> how this is written with your library?
> 
> it doesn't really apply because once a db_ptr is dereferenced the
> transaction 
> is working on a local copy of the object:
> 
> struct A{
> 	int mem;
> 	void do_something(){ ++mem; }
> };
> main(){
> 	db_ptr  a;
> 	a->do_something();
> 	++a->mem;
> }
> 
> only if read-only access is requested the original object is passed to the 
> user, e.g.:
> 
> void do_something(shared  a);
> main(){
> 	db_ptr  a;
> 	do_something(a);
> 	cerr << a.read()->mem;
> }
> 
> 
> what is the intended use of native_trans/transaction_object in your
> library?
> is it:
> struct A{
> 	native_trans<int> mem1;
> 	native_trans<int> mem2;
> };
> A a;
> 
> or is it:
> 
> struct A : transaction_object{
> 	int mem1;
> 	int mem2;
> };
> A a;
> 
> ?
> 
It is up to you to decide what is a transactional object. native_trans<int>
is just a transactional object storing a int and defining the arithmetic
operations. Your first example define a non transactional object containing
two transactional objects. The second defines a transactional object with
two fields.

>>
>> I'm interested. 
> 
> me too, do have an example which shows the final intended use of the
> library?
> I've looked over some of the examples but they seem to be test cases with
> a 
> lot of library internals.
> the example I quoted was from one of the papers on your website.
> 
TBoost.STM intends to implement a lock based SoftwareTransactionalMemory so
there is not need at the user level to use complicated synchronization
mechanism when different threads access some shared data (note that STM do
not support the Durable part of ACID). The user needs to protect whatever
needs to be atomic with atomic {} and use STM smart pointers to access the
transactional data. 

> 
>> Could you add the code to the vault? 
> 
> I didn't know about the boost vault, here it is:
> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=persistence.zip&directory=&
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 

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