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 the DA.)

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
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db

Reply via email to