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

Subject: Re: [boost] persistence library proposal (with prototypeimplementation)
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2009-08-10 04:44:42

Hi,

happy to hear people is concerned with transactions.

Bugzilla from strasser_at_[hidden] 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#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.
> 
> 
Please could you resume which are the main goals of the library? 

Bugzilla from strasser_at_[hidden] 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:
>>
>> 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;
> }
> 

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_at_[hidden] 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_at_[hidden] 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_at_[hidden] 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_at_[hidden] 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-implementation%29-tp24819447p24896247.html
Sent from the Boost - Dev mailing list archive at Nabble.com.