Oracle Backend with SessionPool

Tarball with oracle_pool db backend

Can you modify the files to conform with Django Patch Style?

And I think adding a new backend needs design decision. By patching the existing oracle backend and making pooling an option seems to be better. Making milestone post-1.0 since modifying or adding feature to the current backend is currently out of scope of 1.0 release.

Oracle pooling patch derived from tarball.

Modified patch with print statements removed

I'm trying to run this through the test suite, and I'm seeing lots of non-deterministic test failures. When I try to run the full test suite, I get an early error where it's setting up the test database and apparently trying to reset a sequence that doesn't exist. When I try to run just the basic test, the test runs, but lots of queries return dramatically incorrect results. It's not obvious where this is coming from, but it needs to be addressed before this can be committed.

We have included all changes in this patch(oracle_pool.3.diff). Also has been added 4 settings.
DATABASE_SESSION_POOL=[True/False]
DATABASE_SESSION_POOL_MIN=1
DATABASE_SESSION_POOL_MAX=3
DATABASE_SESSION_POOL_INCREMENT=1

Milestone post-1.0 deleted

Patch against revision 10578 (1.1beta). Use settings.DATABASE_OPTIONS, general code cleanup.

I'm still not able to get cx_Oracle's SessionPool? to behave correctly for the entire Django test suite. I've tried the 4/16/09 patch here as well as my own implementations, but we quickly get test case failures that I've had a very hard time tracking down.

I have not given up--I think this should offer obvious speed improvements. I'm marking this as

...(continued) I'm marking this as needed for the next big release.

I've never looked at the test suite, nor do I have a clue how cx_oracle manages connections and transactions, but perhaps problems arise because some of the tests don't do a commit? The connection would then go back into the pool with an open transaction, and when it was next pulled out of the pool, the state in that connection would be different from what is expected. In general, using any pooled resource can expose sloppy practices in the calling code (failure to properly initialize shared memory, db connection leaks, etc.).

Modified patch against trunk [10832] that passes the Django test suite

Can we have a bit of feedback about if the patch is supposed to work correctly now and it's effectivity?

The patch works as far as we've seen. The issues that were arising in the test suite had to do with the test setup attempting to disconnect, change the connection parameters, and reconnect, which failed because of the pool. For the same reason, I suspect it will take some work to make this compatible with the multidb branch, but otherwise it's usable.

The patch didn't work for me for 1.0.X branch rev10865. I attach al alternative patch for this version.

Oracle Pool for 1.0.X branch

I found that the used SessionPools? getmode parameter may no match everybody's requirements. This should be a parameter. Would be great if this really was a parameter of p.acquire()

Bad news: I get DatabaseError: ORA-03135: connection lost contact with cx_Oracle 4.4.1 which does not drop/release/reconnect the connections. After the all connections are acquired, I get: ORA-24418: Cannot open further sessions. As it's author in the cx_Oracle mailing list suggest, a pool.drop(connection) is not enough, as it raises another exception. The complete pool may be replaced.

I have packaged up a version of this pooling backend, and made it available on pypi

see http://pypi.python.org/pypi/django-oraclepool

This includes some tests, and other extra little bits. It has also been tested against 1.1 and 1.2

- Ed Crewe

We are past the feature phase of 1.2.