Hi, happy to hear people is concerned with transactions. Bugzilla from strasser@uni-bremen.de wrote:
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:
<> 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.
Please could you resume which are the main goals of the library? Bugzilla from strasser@uni-bremen.de wrote:
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; }
The current version include as well smart pointers, read pointers rd_ptr<T> and wr_ptr<<T>. Here it is how we can do this now: native_trans<int> global_int; int increment_global() { atomic(t) { wr_ptr<int> tx_global_int(global_int,t); (*tx_global_int)++; return *tx_global_int; } } 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 this is written with your library? Bugzilla from strasser@uni-bremen.de wrote:
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)
TBoost.STM use different pointers to track this. * rd_ptr allows only to read the value * wr_ptr allows to read/write the value we are adding a upgrd_ptr that allows to read the value and also to be upgraded to a writable pointer. So, we know some memory can be written by a transaction when a wr_ptr is initialized. Bugzilla from strasser@uni-bremen.de wrote:
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.
I'm interested. Could you add the code to the vault? Bugzilla from strasser@uni-bremen.de wrote:
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.
Why do you need to use files to track the memory changes, why don't just memory? Bugzilla from strasser@uni-bremen.de wrote:
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Best, 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.