I'm wondering if a better name might be something like
transaction process library
the term "persistence" was taken from the boost.serialization documentation, explaining why boost.serialization was not called boost.persistence: <<I found that persistence is often used to refer to something quite different. Examples are storage of class instances (objects) in database schema [4] This library will be useful in other contexts besides implementing persistence.">> http://www.boost.org/doc/libs/1_36_0/libs/serialization/doc/rationale.html#s... I'm open to name changes of course, but transaction process library misses the "transparent persistence" part. transaction processing and transparent persistence may seem like two very different libraries, but persistence isn't very useful without atomic transactions, especially when you add reference counting to the mix: one application crash and the database never will get garbage collected again.
By the way the Wikipedia article on STM (http://en.wikipedia.org/wiki/Software_transactional_memory) has a reference to a library that already implements STM for C++ and is aiming to become part of Boost:
thanks for the link.. I only took a short look at it so far, here's an example using boostSTM: template <typename T> class native_trans : public transaction_object< native_trans<T> >{ ... }; native_trans<int> global_int; int increment_global() { transaction t; transaction_state state = e_no_state; int val = 0; do { try { t.write(global_int).value()++; val = t.read(global_int).value(); state = t.end_transaction(); } catch (aborted_transaction_exception&) { t.restart_transaction(); } } while (state != e_committed); return val; }
How do you track that a balance field is modified? And how do you know which account objects were modified in a given transaction?
my focus was on providing a user interface as close as possible to conventional memory usage, so I decided against tracking the modification of individual fields (and thus requiring the user to provide such information). changes are tracked on a per-object basis rather than per-field. this is accomplished via the smart pointer I mentioned, db_ptr. it provides almost the same interface as smart_ptr does, plus: class db_ptr{ //explicitely: shared_ptr<T const> read() const; shared_ptr<T> write() const; //implicitely: operator shared_ptr<T const>(); operator shared_ptr<T>() const; shared_ptr<T> operator->() const; ... } . when converting db_ptr to a non-const shared_ptr or using operator->, the intended use (read or write) can not be determined at this point so the library notes that the object may or may not have been modified. on commit, those objects are compared to the original object instance to determine whether the object has been modified (to avoid unnecessary object updates and isolation_exceptions)
And it is interesting to know what level of isolation the library provides or is supposed to provide.
serializable, for successful transactions.
you are actually providing an STM solution
I must admit that I've never heard that term before. I'll have a closer look at BoostSTM, but at first glance it looks like two very different approaches (with similar underlying principles)
Can you please post links to the source code? Maybe you have a web-site you use to host the library?
no website. I can upload it somewhere or mail it to someone with access to a repository, e.g. boost sandbox? as complex as this might sound, the whole thing currently is only about 1500 lines of code. with very poor performance, but that's mostly due to the current storage backend, using one file for each object, so you end up with thousands of files, a few bytes each.