Re: Beating Oracle

> Certainly there's value in providing a framework that helps the client
> to deal with this.  I was just objecting to what might have been a
> misreading of your meaning: it seemed you were saying that libpqxx
> solves the problem so the client doesn't have to think about it.

Basically, the framework lets you write your transaction as a functor class 
derived from the Transactor class.  In return for this effort, the 
execution code does its best to minimize the risk window (which currently 
still exists, but I'd like to work to "eliminate" it insofar as this can be 
done).

The setup of Transactor encourages the programmer to put all "transient" 
state involved in the transaction inside the functor class as data 
members.  If the connection is no longer there, for example, the framework 
tries to rerun the functor.  It first restores the transaction's initial 
state simply by copy-constructing the functor object.  If any results or 
other changes need to be written back to the rest of the program, this can 
be done from the optional OnCommit() method (or the programmer may opt to 
write results back to the program's state immediately, and write undo code 
in the optional OnAbort() method).

I think the interface isn't too bad, and next it would be worthwhile to 
install more solid ACID support behind it.  It's not quite "a poor man's 
XA" but my toes curl when I think of every programmer having to deal with 
these issues for himself.


Jeroen