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