However, a colleague found out that for his (probably special kind
of) setup, "cxOracle" was much slower than DCOracle2 (by about
a factor of 4).
heh, well I like to write FAST code when I can ;) However, the Zope
DA/RDBMS machinery slows the db conection down enormously -- like 9x
if I recall. DCOracle2 is very fast at getting you to the Nth result
in a result set as long as you don't make it turn all the prior
results into python objects first (which is, sadly, the behavior of
What happens with Zope and DCOracle2 I think is when the DA
connection object is ghosted, it doesn't know about it, and thus
doesn't close its connection. There may be some grief that it also
doesn't close the right connection object (if I recall, there is an
actual close() method on the underlying C connection object, but I'm
not sure if the DA ever calls it). The close is implicit when the
connection object is destroyed, but usually there's so much stuff
loaded that *someone* has a reference to the connection.
However, the code is still geared around OCI8 and some Oracle 9 code,
its due for some refactoring in a big way to deal with the profusion
of handle-driven objects now much more prevalent in Oracle 10.
Zope-DB mailing list