> 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.
....And of course I should have added that the rerun involves setting up a
new back-end transaction (which is again handled by the framework).
I've considered special-case optimizations such as recording & replaying
SQL, but felt a bit out of my depth when trying to define (in reasonably
simple terms) when this would be safe. After all the client's transaction
may eg. read a record that another client may have modified between
retries. So I stuck with the more general solution of replaying the client
code, and coupling each attempt to its own backend transaction.
Of course this still doesn't let you do long transactions in an iffy
network environment. What it does buy you--I think--is the ability to keep
a connection open for a long time and running batches of smaller
transactions, without having to care (much) about temporary loss of
connection. From what I've seen, such loss typically occurs when the
connection is idle between transactions.
Jeroen
