A solution to the plethora of time_wait problems with Oracle and C3P0 databases.

Project is b/s mode, placed on a Linux server, Tomcat and oracle11g on a server, Tomcat read database using C3P0 connection pool, has been relatively stable, so there is no pipe. Later, the Tomcat was placed under one win2008 and the database was placed under another win2008. Run for more than half a month, during the regular Report database connection error, but refresh the next page is also good. Because it is an occasional problem, but also not to pay attention to. Finally one day a complete error can not be entered, the error is as follows:

The effect is that there is a problem with the database connection. That's laughed. Open the database server to see why. The database looks normal, but is not connected with sqlplus, the maximum number of connections is reported. So with Netstat-ano, the intention is to see if the listening port is normal monitoring. Never wanted to have more than 400 1521 ports of time_wait information:

No wonder the database is not connected, so the database has been restarted for the time being. Viewed for half an hour, the database connection remained at around 50, thought to be normal. In the afternoon, worrying, and on the server to see a bit, obediently, and more than 200 time_wait. Fortunately found early, or in a few days must have a problem. Then Google Baidu search for a while, seemingly this problem appeared at home and abroad many, according to a simple solution:

In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, add the DWORD key named TcpTimedWaitDelay, set to 60, To shorten the waiting time of time_wait

Add a MaxUserPort value of 65534 at the same time

There has been no such problem ever since. I have been wondering, configuration is similar, is the win system and Linux system performance difference, I think it can not ah, not so much. This matter has been in mind, one day suddenly remembered that the original Linux is because the Web and the database on the same server, the Web and the database is through the local process communication, does not involve the TCP protocol. And then win system is separate two, two low-level is through the TCP Exchange data. Due to some default settings of the win system, the free database connection of TCP is not released in time after the database connection pool is exhausted. TCP connections continue to increase, slowly exceeding the limit. After the TcpTimedWaitDelay is configured, the TCP connection is automatically freed after 60 seconds of inactivity. As a result, 50 or so stable connections are maintained under normal conditions.

I think it should be so, sometimes looking at the database pool useful, but in fact, the lower layer did a package. The lower level setting is still configured.

A solution to the plethora of time_wait problems with Oracle and C3P0 databases.