Further to my previous entry about DCOracle2 it transpires that there are a few more issues which need resolution, in addition to the strange insert error message:
- the client will be using Oracle DataGuard to ensure a replicated standby of their database is available. In the event of a fail-over the Zope-to-Oracle connection will be severed and runtime errors will ensue. There are two obvious ways to fix this:
- use a standard_error_handler
- add something to the Zope instance which reconnects the database connection and reloads the current page, but this could be messy in a number of ways.
- patch DCOracle2:
- perhaps the logical place to put the reconnection code as it is a function of Oracle’s client libraries and one’s tnsnames.ora configuration that this fail-over can be made to happen seamlessly.
- looking at db.py it seems as though it was possible to the results of two queries appended to each other by separating the two queries with a NUL byte (ASCII 0), but when I tried this I found that both queries had to present the same schema (in which case there is no advantage over an SQL union) and I still received runtime errors when they did have the same schema.
- arbitrary limit of 9999999 rows will be fetched
- various globals in db.py are definitely not good for concurrency, and so they’ve been hacked out
The result is DCOracle2 v1.3i, available as source tarball and patch to be applied to v1.3b patched to v1.3f.
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”).
