On Thu, January 4, 2007 07:23, Joshua Moore-Oliva wrote: > Well, sorry to spam you all but I have a framework that appears to work, > at > least without throwing errors. I've basically copied and pasted > transaction, > except I had to pull in basic_transaction since it declared do_commit() as > private.
It turns out to be pretty hard to simulate failure. I've often wanted to add this for testing, but the question was always how to pinpoint the exact failure points you'd like to test through all the layers of software. The transaction part isn't all that hard, really: instead of inheriting from transaction, try inheriting a new transaction class from dbtransaction. Just make sure your transaction class constructs and destructs like the "transaction" class template does, and copy the do_commit() function from basic_transaction. Then add some code to make the connection fail to the very beginning of do_commit, and instantiate your transactor to use your new transaction type. The hard part, really, is making the connection fail in a way that will cause maximum inconvenience. Turns out the code is just too robust to let things fail very nastily. So I've just added a new function connection_base::simulate_failure(). Just check out the latest Subversion tree and look at the new test program I added, test094.cxx. This also means that in-doubt states are now regularly tested (and they turned out to work just fine, thank heavens). Jeroen _______________________________________________ Libpqxx-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
