you can also look in V$SESSIONS or under unix
with netstat -a | grep 1521 how many connections
are established.
regards, tom
> -----Urspr�ngliche Nachricht-----
> Von: Lukas S�gesser [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 22. Juni 2001 11:59
> An: [EMAIL PROTECTED]
> Betreff: Re: mysteriously dying connections (Oracle <-> tomcat)
>
>
> i checked this over and over again. i really do return all the connetions.
>
> ----- Original Message -----
> From: "Ralph Einfeldt" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, June 21, 2001 5:30 PM
> Subject: AW: mysteriously dying connections (Oracle <-> tomcat)
>
>
> > It sounds to me like you're not alway returning the
> > connection to the pool or not closing the connection.
> >
> > But this is hard to say without the source of your
> > java class.
> >
> >
> > If you use a connection pool where you have
> > access to the source code, look if the get and release
> > methods can be intrumented in a way to log each
> > get and release with the hashcode of the connection.
> > Otherwise log each call to get/release in your own code
> > or build a wrapper object around the pool that log
> > this information before calling the pool method.
> >
> >
> > > -----Urspr�ngliche Nachricht-----
> > > Von: Lukas S�gesser [mailto:[EMAIL PROTECTED]]
> > > Gesendet: Donnerstag, 21. Juni 2001 16:38
> > > An: [EMAIL PROTECTED]
> > > Betreff: mysteriously dying connections (Oracle <-> tomcat)
> > >
> > >
> > > hi all!
> > >
> > > problem:
> > > --------
> > >
> > > database access is managed via a java class that is
> > > instantiated and loaded into each clients session. every
> > > PL/SQL function and/or SQL statement a client needs is
> > > called in a method of this class.
> > > first, a connection is opened, the statement is called,
> > > all resultsets and statements are closed and finally the
> > > connection is closed. (or returned back to the
> > > connection pool if one is used)
> > >
> > > the driver we use is the Oracle jdbc ThinDriver (jdbc
> > > driver type 4). after running the system for several
> > > days, dead connections (and as we just discovered, tons
> > > of open cursors) pile up.
> > > eventually the webserver(tomcat) will crash or just
> > > hang.
> > > in the process, access gets slower and slower, there may
> > > be delays of 3 minutes until the webserver (or, perhaps
> > > the database, in which case the webserver would be just
> > > waiting for the db..) gives a response.
> > > after a restart of the webserver or the database or
> > > both, the system runns very well again.
> > >
> > > we tried several connection pools. with these, there
> > > were no delays for getting a connection, but the pool
> > > threw timeoutExceptions (i.e. made it visible that there
> > > are hanging connections) and after a few hundred
> > > timeouts the VM crashed with a stack overflow.
> > >
> > > the connections seem to get killed/kill themselfes
> > > randomly no matter which function was called. we log the
> > > methods and statements that were called for the
> > > connections that die, but there is just no pattern in
> > > it. thats why we dont find the root of the problem.. is
> > > it the driver ? the database ? the tomcat ?
> > >
> > >
> > >
> > > environment:
> > > ----------------
> > >
> > > Web Server:
> > > Suse Linux 7.2
> > > Apache Webserver /w Tomcat JSP Engine 3.2 /w SSL
> > >
> > > DB Server:
> > > Suse Linux 7.2
> > > Oracle 8i 8.1.7 /w multi-threaded server (MTS)
> > >
> > > Backup Server:
> > > Oracle Shadow server
> > >
> > >
> > >
> > > things done:
> > > ------------
> > >
> > > - linux update
> > > - apache update
> > > - tomcat update
> > > - jdbc thin driver update
> > > (everywhere the newest version)
> > > - tried several connection pools
> > >
> > >
> > >
> > > possible changes:
> > > -----------------
> > >
> > > - use OCI drivers instead of thin driver
> > > - use J-serv with GNU_jsp instead of tomcat
> > >
> > >
> > >
> > >
> > > every help is welcome, we're frustrated to no ends.
> > > thanks very much in advance!!
> > >
> > > l.s�gesser
> > >
> > >
> >
>
