Connection pooling for DB-API connections.
Provides a number of connection pool implementations for a variety of usage scenarios and thread behavior requirements imposed by the application, DB-API or database itself.
Also provides a DB-API 2.0 connection proxying mechanism allowing regular DB-API connect() methods to be transparently managed by a SQLAlchemy connection pool.
Remove all current DB-API 2.0 managers.
All pools and connections are disposed.
Returns a proxy for module that automatically pools connections.
Given a DB-API 2.0 module and pool management parameters, returns a proxy for the module that will automatically pool connections, creating new connection pools for each distinct set of connection arguments sent to the decorated module's connect() function.
Arguments:
See the Pool class for options.
A Pool implementation that allows at most one checked out connection at a time.
This will raise an exception if more than one connection is checked out at a time. Useful for debugging code that is using more connections than desired.
A Pool implementation which does not pool connections.
Instead it literally opens and closes the underlying DB-API connection per each connection open/close.
Base class for connection pools.
This is an abstract class, implemented by various subclasses including:
The main argument, creator, is a callable function that returns a newly connected DB-API connection object.
Options that are understood by Pool are:
Construct a new Pool.
dispose of this pool.
this method leaves the possibility of checked-out connections remaining opened, so it is advised to not reuse the pool once dispose() is called, and to instead use a new pool constructed by the recreate() method.
Use Queue.Queue to maintain a fixed-size list of connections.
Arguments include all those used by the base Pool class, as well as:
Construct a new QueuePool.
Maintains a single connection per thread.
Maintains one connection per each thread, never moving a connection to a thread other than the one which it was created in.
This is used for SQLite, which both does not handle multithreading by default, and also requires a singleton connection if a :memory: database is being used.
Options are the same as those of Pool, as well as:
Dispose of this pool.
this method leaves the possibility of checked-out connections remaining opened, so it is advised to not reuse the pool once dispose() is called, and to instead use a new pool constructed by the recreate() method.
A Pool implementation which stores exactly one connection that is returned for all requests.