> -----Original Message----- > From: cjder...@gmail.com [mailto:cjder...@gmail.com] On Behalf Of chris > derham > Sent: Thursday, June 28, 2012 10:47 AM > To: Tomcat Users List > Subject: Re: Tomcat 7.0.28 connection pool issue > > On Thu, Jun 28, 2012 at 12:38 PM, Yasser <yarafa...@gmail.com> wrote: > > > Yes. It does show that maxactive has reached 100. I also use splunk > to > > get the connection status at the oracle side. > > What I dont understand is that Resin needs just 50 connections to > > handle the same load. I am in the process of increasing the count to > > 300 and see if that makes a difference. Oracle has the capacity to > > handle that many connections. > > > > We hit an odd oracle exception that may be related. Can't explain it > really well, but the essence of the bug in Oracle was that the > tnslistener's connection count wasn't updated "regularly enough" when > connections closed, so it could believe that the connection limit had > exceeded when the db instance was still happy to accept more > connections. > As I recall this was a known Oracle issue, and was fixed by increasing > the acceptable connection count in Oracle. Can you provide the exact > exception from the logs that you hit?
Chris, this is one of the reasons for using a pool. Since the physical DB connection between Tomcat & Oracle is never actually closed in a pool scenario, you don't run into this problem (unless, of course, you have some other app also connection to the DB and not using a connection pool). It's a function of how Oracle is designed, the Listener adds one to the "open" count for each new connection, and then hands the connection off to another process. At this point, the Listener no longer cares about the connection, and is not involved in "closing" the connection. There is another Oracle process that periodically updates the Listener with the actual current count of connections. I'm not sure what the "periodically" is set to, something like 10/15 seconds. Think of it as analogous to the TIMED-WAIT status of TCP connections (something that also easy to get caught up in without a connection pool). Jeff __________________________________________________________________________ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
