Oracle Database Connection objects dont close
this is a follow up. I just tried to close my Oracle database connection object and my ZSQLMethods still use it. so it appears that Open/Close in the DCOracle2 beta5.zip dont work. Zope2.4, DCOracle2 beta5.zip, WindowsNT should I post this to the DCOracle tracker or to the Collector? ~runyaga
alan runyan wrote:
this is a follow up. I just tried to close my Oracle database connection object and my ZSQLMethods still use it. so it appears that Open/Close in the DCOracle2 beta5.zip dont work.
Zope2.4, DCOracle2 beta5.zip, WindowsNT
should I post this to the DCOracle tracker or to the Collector?
~runyaga
This is a misfeature in Aqueduct, AFIAK, where "closed" connections are automatically reopened on demand by the application. There is no "administratively closed" state. If, at some point in time, I get *REALLY MAD* at Aqueduct (enough to actually start attacking it) I may attempt to address this by letting connections have more than a binary state of open/closed -- more like: Administrative State 'enabled' 'disabled' Connection State "connected" UP OFF "disconnected" ON DOWN That way, you could have the connection be "on" and have it be automatically connected when required. (Note that that grid isn't perfect -- how you can be connected and disabled and call it "OFF" is a misnomer, but it represents a transit to the "DOWN" state). The big gotcha with things like Aqueduct is that it isn't at all required that the core class have certain methods which get invoked to manage connection state -- because the core class is subclassed by each connection type. So it is not necessarily easy to retrofit new behavior without having to touch all known instances of products which subclass it -- not a pleasant prospect. I'm in favor of trying to split Aqueduct into halves -- one which provides core RDBMS connection support and one which provides the useful report stuff, and attempting to provide updated guidelines for making RDBMS adapters to Zope. In particular, I'd love to see more query-builder type things available, which would require some rudimentary discovery mechanisms -- some of which are already there (ie the table browser). The core splitting shouldn't be too bad, but there may be a lot more gotchas in trying to provide a migration path. Anyway, this is all more "wouldn't it be nice if..." rather than any concrete action plan.
participants (2)
-
alan runyan -
Matthew T. Kromer