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:
all changes made by change_objects() should be undone if tx is destroyed
without calling commit(), e.g. because of an exception thrown by
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
while(current) current=current->next; //operator-> loads the next node
--- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk