DCOracle2 Concurrency Issues with Oracle 10g
A client was starting to see concurrency issues using DCOracle2 in their development/testing environment, and was concerned that once the system was put into production the support calls would start to flood in. Initially I thought I had fixed the problem by upgrading from v1.1 to v1.3b (despite being a beta release v1.3b does seem to be of fairly high quality). My testing with v1.3b seemed positive, but I had neglected to test one thing: concurrent accesses with different users!
I can only theorise that somehow the acl_users object, which is an LDAPUserFolder in this instance, was effectively serialising requests from the same user. A little educated guesswork suggested a fix: to make a new cursor for each query and assume that the underlying dco2 module was thread-safe at a cursor level (threadsafety level 2 in the DB-API 2.0).
The result:
- patch for v1.3b
- apply with patch < 20061010-DCOracle2-v1.3b-db.py.patch
- source tarball which I have called v1.3f ("f" standing for Faelix)
- includes Debian Sarge Python 2.3 binary for i386
Follow-Up
It seems that there may be another bug in the DCOracle2 madness: an insert query which is malformed will not provide a useful error message. Instead one will be confronted with a cryptic statement to the effect of "your statement wasn't a SELECT query". This is completely unhelpful, and seems to be caused by either db.py or DCOracle2/DCOracle2.py as the dco2 module is unaffected and raises the appropriate intelligible error.
The solution seems inevitable: I shall have to release v1.3i ("i" for "insert").