mozilla/configman — pull request #13 by twobraids (2011-12-20 16:19:24+00:00)
Title: proposal for database interaction

This is a demonstration of a way of interacting with a database (or any external data store) using configman.

this is an advanced demo uses configman to allow an app to not only change
the database implementation at run time, but to change the overall behavior
of the database. Three families of classes are used in this demo:
1) FakeDatabaseConnection - there is only one member of this family. It is
used to simulate a database. Understanding this class is unimportant
in understanding the rest of the app. It is just a mock.
2) Postgres; PostgresPooled - This two member class hierarchy shows how to
wrap a database module with configman to implement a transaction
context.
* The base class 'Postgres' implements a system where each database
connection is opened, used once, and then closed. Normally, this
would be a pretty inefficient way to implement a database intensive
application. However, if an external connection manager is in use,
this is a fine model for connection management.
* The second class in the hierarchy implements a different connection
management strategy. Here connections are pooled for reuse by name.
Defaulting to the model of one connection per thread, it uses the
name of the current executing thread as the name of the connection.
However the facility exists to name connections with any string.
This class implements a more efficient way to run a database
intensive app because connections get recycled.
3) TransactionExecutor, TransactionExecutorWithBackoff - this two member
family implements two behaviors of transactions.
* The base class 'TransactionExecutor' is the simple case where a
a transaction is submitted and it either succeeds or fails.
* The derived class 'TransactionExecutorWithBackoff' will try to
execute a transaction. If it succeeds, it does nothing more. If it
fails with a database operational error (connection lost, socket
timeout), the transaction is retried over and over util it
suceeds. Between each subsequent retry, execution sleeps for a set
or progressive number of seconds. Exceptions deemed non-operational
are passed out to the application and do not trigger retries.
The latter two class families are settable using configman at run time. The
demo app logs its actions, so we suggest trying different combinations of the
Postgres and TransactionExecutor families to observe how they differ in
behavior.