Skip to main content

django database backend that uses cx_Oracle session pooling for connections

Project description

ILRT Django Oracle pool

Ed Crewe, ILRT at University of Bristol, January 2010

Packaged version of by Taras Halturin django database backend that uses cx_Oracle session pooling for connections

Original Code Modifications

Pruned original ticket’s to just hold the pooling relevant code. Using the standard Oracle connection for the rest of the database classes, ie. operations, client and introspection.

Tested with django 1.1 and 1.2, deals with the differences eg. to settings handling.

Extra features

  • Added the pooling and logging parameters to the settings.
  • The connector uses the standard python logging model and caters for logging full details of queries, either to a file log or appending them to the bottom of the screen if the log level is DEBUG.
  • Added an option for running against existing (older) Oracle databases, ie those which may not have unicode for character fields.
  • Option also allows running the tests against an existing database so that running tests doesnt require database creation (oracle sys dba) rights.
  • Added a modification to the cursor to not parse parameters if not required.

Why use it?

Perhaps due to our remotely distributed Oracle network taking a very long time to establish connections, the use of cx_Oracle’s session pooling for connections provided a truely radical performance boost for requests from 3-4 secs/req to 0.4 secs/req, ie a 900% performance increase !!

For single direct Oracle access it might still give a doubling of performance. Install it and run the performance test to find out (see below).


Download the egg (or use buildout) or download the tarball and extract it. Then add /path/to/django-oraclepool to your python path.

Specify DATABASE_ENGINE = ‘oraclepool’ instead of ‘oracle’ in your settings.

If you dont want to use the default extra database settings then the following defaults are used

>>> DEFAULT_EXTRAS = {'min':4,        # starting number of pooled connections
...                  'max':8,         # maximum number of connections in the pool
...                  'increment':1,   # increase by this amount when more are needed
...                  'homogeneous':1, # 1 = single credentials, 0 = multiple credentials
...                  'threaded':True, # server platform optimisation
...                  'timeout':600,   # connection timeout, 600 = 10 mins
...                  'log':0,         # extra logging functionality turned on
...                  'logfile':'',    # file system path to log file
...                  'existing':''    # Type modifications for existing database and flag for tests
...                  }

General Performance

Initially after apache restart you will see the first few requests taking the same time as each one initiates a new pooled connection. Then request speed should drop as it loses the Oracle connection time.

NB: Note that if you have PythonDebug On then the pool may get flushed much more regularly. So you will often get the slower pool populating requests.

Using mod_wsgi rather than mod_python may give a 25% added increase although this needs confirmation on a production instance.

Pooling alternatives

Pyora pool

Also tried out pyora pool see but found increase was only around 90% and also had issues with connection control and database edits failing. This also requires the whole architecture of a separate remote procedure call daemon that holds the connection pool. Uneccesary here … although useful for pooling across different applications, or multiple servers.

ORM pools

Usually ORMs have a generic pooling capability, unfortuately djangos only has a beta one in development, unless you plugin another ORM, eg. instead. However that does require code rewriting.

Having said that a generic ORM level pool is unlikely to perform as well as one at the database connector level, which in turn is going to be less fast than one within the database itself (see below).


The tests are run via separate test apps in the django-oraclepool folder. Some of these tests are derived from a set for

They also include the option to run the test suite against an existing database for users who dont have full oracle dba rights on their test oracle servers.

The key extra tests are performance timings for running the test suite via the pooled oracle connection vs the standard one. Hopefully these timings should indicate whether using oraclepool is of value when using django with your oracle server network.

Run the tests by running django-oraclepool/tests/ test Or run individual tests by supplying there name, eg. test performance

The performance test simulates a real environment by running up a number of connections as would exist with a production web server (the Apache2 default is 2 processes * 64 threads) whilst the test creates a maximum of only 32. In practise I found the actual performance improvement significantly greater than that indicated by the doubling of speed that the multiple connections performance test gives. However that may not be the case dependent on your production oracle and web server environment.


  • Oracle 11g has internal session pooling - DRCP - and cx_Oracle can use that for even better performance, so need to add appropriate modification to test whether the database 11g or later, and use this feature in place of a cx_Oracle side pool. NB: requires cx_Oracle 5, see


0.4 - Fix performance test (2010-01-29)

  • Whoops, I realised the performance test was underplaying the improvement due to a bug, it now gives the same performance for single connections (as expected) and 300% improvement for multiple ones.

  • Added signal for connection ‘creation’ and fixed raise of unicode error

    [Ed Crewe]

0.3 - Initial release (2010-01-28)

  • Added test suite including performance test to demonstrate benefits

  • Tested and made compatible with django 1.2 (as well as django 1.1)

  • Cleaned up the code and factored out anything that wasnt specific to pooling, subclassing most components from the standard Oracle engine.

  • Modified logging options so DEBUG switches on log to screen and EXTRAS[‘log’] switches logging to file option separately.

    [Ed Crewe]

0.2 - Used for UoB student reps

  • Commented out debug print statements from DatabaseWrapper._cursor which broke install in wsgi

  • Added DatabaseWrapper.__init__ like the oracle backend with client, creation and introspection borrowed from it, since creation is expected in django 1.1.1 code.

  • Added default value of None for settings in DatabaseWrapper._cursor since this argument is not expected in django 1.1.1 code.

  • Added DATABASE_EXTRAS dictionary to set all the session parameters from django config.

  • Added session pool settings report method, to check these.

  • Added python logger option and sql_log middleware

    [Ed Crewe]

0.1 - Unreleased

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Filename, size & hash SHA256 hash help File type Python version Upload date
django_oraclepool-0.4-py2.5.egg (24.2 kB) Copy SHA256 hash SHA256 Egg 2.5
django-oraclepool-0.4.tar.gz (33.2 kB) Copy SHA256 hash SHA256 Source None

Supported by

Elastic Elastic Search Pingdom Pingdom Monitoring Google Google BigQuery Sentry Sentry Error logging AWS AWS Cloud computing DataDog DataDog Monitoring Fastly Fastly CDN SignalFx SignalFx Supporter DigiCert DigiCert EV certificate StatusPage StatusPage Status page