Re: Beating Oracle

> 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