Re: [boost] persistence library proposal (with prototypeimplementation)

Subject: Re: [boost] persistence library proposal (with prototypeimplementation)
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-08-10 01:34:36

> 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#serialization

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:
>
> http://eces.colorado.edu/~gottschl/tboostSTM/index.html

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.