already tried that... didn't work... as a matter of fact, the pool had no effect on the problem, it stayed the same... .:| Christian J. Dechery .:| FINEP - Depto. de Sistemas .:| [EMAIL PROTECTED] .:| (21) 2555-0332
>>> [EMAIL PROTECTED] 21/08/02 15:12 >>> You need a connection pooler. The Oracle Drivers come with support for connection pooling. > -----Original Message----- > From: Christian J. Dechery [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 21, 2002 1:01 PM > To: [EMAIL PROTECTED] > Subject: problems with Connections > > > I have this big problem handling Oracle Connecions... > > something goes wrong... I have tons of classes called > DAO"Something"... and a class called DAO which provides the > Connection... the DAO*s requests the Connection from DAO and > uses it, but there is no method to close the connection since > it is used by several methods that run queries (selects and > updates)... > > I don't know what goes wrong... but after some time of using > the applicatiob the maximum number of cursors exceeds and the > whole application stops, cuz no more queries will run... and > I am closing ALL ResultSets and Statements on the "finally" > block of EVERY query... > > this happend when I dispense one Connection to several > classes, thus achieving some kind of sharing... if I turn > that sharing off - every class will get an exclusive > Connection, the problem changes... now instead of the maximum > number of cursors exceeding, I get maximum number of > processes (connections)... > > the connections (nor the cursors for that matter) are getting > closed... I even tried placing a con.close() on the > finalize() method of the DAO*s... but that didn't work... I > get an IOException: socket closed... > > At the Oracle support service, I saw that a lot of people has > the exact same problem.. > > does anyone knows how to solve this??? > > thanks > > btw: I have a "solution" working now... I changed the code of > my DAO*s, so that every method that runs a query, requests a > connection, than closes it... but that makes some parts of > the application veeeeeeeeery slow... > > .:| Christian J. Dechery > .:| FINEP - Depto. de Sistemas > .:| [EMAIL PROTECTED] > .:| (21) 2555-0332 > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
