[boost] persistence library proposal (with prototype implementation)

Subject: [boost] persistence library proposal (with prototype implementation)
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-08-04 18:47:48

Is there any interest to include a persistence library in boost, built upon 
the boost serialization library?

the basic idea is:

transaction tx;
change_objects();
tx.commit();

all changes made by change_objects() should be undone if tx is destroyed 
without calling commit(), e.g. because of an exception thrown by 
change_objects().

the library should provide ACID transaction properties, so that multiple 
transactions (in different threads) can work on the same objects and 
conflicts are discovered by the library. further, an application crash should 
be recovered, with the changes made by a transaction either committed as a 
whole or undone.

to partition your object model into many different objects, which can be saved 
to disk and loaded back on demand, there is a new smart pointer introduced, 
which behaves like smart_ptr and is convertible to smart_ptr.
objects that are handled by this smart pointer and are no longer used in 
memory are not destroyed but saved to disk. only objects which are no longer 
in use either in memory or on disk are destroyed.

the only requirement on persistent objects would be to model the 
concept "Serializable" as defined by boost serialization.

e.g. a linked list, whose elements are loaded from disk on demand could look 
like:

struct node{
        db_ptr<node> next;
private:
        //Serializable requirements
};
void traverse(){
        while(current) current=current->next;  //operator-> loads the next node
}

prototype implementation
---
i've attached a test case using the current implementation.
it demonstrates multiple concurrent transactions.running isolated from each 
other.
it models a bank, with multiple threads constantly withdrawing from one 
(random) bank account and depositing the amount on another.
when two threads are using the same bank account at the same time, resulting 
in money being lost, an isolation_exception is thrown in one of the threads 
and the transaction can be restarted. there is no manual thread 
synchronization involved.
the current implementation uses an optimistic multiversion approach,
meaning that each transaction running concurrently is working on its own copy 
of an object. when the transaction is committed conflicts are discovered and 
an isolation_exception is thrown.
several things like reference counting on disk and the recovery process after 
a crash aren't implemented yet, but the basics are in place and should give 
you an idea of what kind of a library I'm proposing.