> 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
