Solve the problem of tomcat dying frequently

Solve | The problem

One day on the server on the Web page is not open, frequently reported the following error.

2007-3-18 1:08:26 Org.apache.tomcat.util.threads.ThreadPool Logfull
Serious: All threads (are) currently busy, waiting. Increase MaxThreads or check the servlet status

On the internet to find some answers, I think the following is the correct answer:
1. I think that some of your resources have not been released, the backlog of cards dead
2. Connection pooling problem
3. Should be the server-side response request thread processing time caused by too long

Analysis:
At that time, the number of people using the site is only 2, it is impossible to answer to the concurrent thread 150 of the online. So it should not be a database problem.
Judging by the error, the connection pool should be used unreasonably or no connection pool is set up at all. The portion of the connection to the database is JDBC connected using spring's data source, as follows:
<beans>
<bean id= "DataSource" class= "Org.springframework.jdbc.datasource.DriverManagerDataSource" >
<!--driver for mysql-->
<property name= "Driverclassname" ><value>org.gjt.mm.mysql.Driver</value></property>
<property name= "url" ><value>jdbc:mysql://localhost:3306/test?useunicode=true&characterencoding= Utf8</value></property>
<property name= "username" ><value>test</value></property>
<property name= "Password" ><value>test</value></property>
</beans>

The problem should appear on spring's drivermanagerdatasource, which is responsible for managing these connections.
Below is an explanation of Drivermanagerdatasource.
Drivermanagerdatasource in Spring Framework

Javax.sql Interface DataSource

Implementation of Smartdatasource that configures a plain old JDBC Driver via
Bean properties, and returns a new Connection every time.

Useful for test or standalone environments outside of a Java EE container, either
As a DataSource bean in a respective applicationcontext, or in conjunction with
A simple JNDI environment. Pool-assuming Connection.close () calls to simply
Close the connection and so any Datasource-aware persistence code should work.

In a Java container, it is recommended to use a JNDI DataSource provided by the
Container. Such a DataSource can be exported as a DataSource bean
ApplicationContext via Jndiobjectfactorybean, for seamless switching to and from
A local DataSource bean like this class.

If You are need a "real" connection pool outside of a Java container, consider
Apache Jakarta Commons. Its basicdatasource are a full connection pool
Bean, supporting the same basic properties as this class plus specific s Ettings.
It can be used as a replacement for a instance of this class just by changing
The class name of the Bean Definiti On to
"Org.apache.commons.dbcp.BasicDataSource".

-----------------------------------------------
Many Jakarta projects support interaction with a relational Database. Creating a
New connection for each user can is time consuming (often requiring multiple
seconds of clock time), in Order to perform a database transaction that might
take milliseconds. Opening a connection per user can is unfeasible in a
publicly-hosted Internet application where the number of Simultan Eous users can
be very large. Accordingly, developers often wish to share a "pool" of open
connections between all of the application ' s current user S. The number of users
actually performing a request at any given the "is usually a very small
percentage of the T Otal number of active users, and during request processing is
This only time this a database connection is required. The application itself
logs into the DBMS, and handles any user account issues internally.

There are several Database Connection pools already available, both within
Jakarta Products and elsewhere. This Commons package provides a opportunity to
Coordinate the efforts required to create and maintain a efficient,
Feature-rich package under the ASF license.

The COMMONS-DBCP package relies on "code in" Commons-pool package to provide
The underlying object pool mechanisms that it utilizes.

Applications can use the COMMONS-DBCP component directly or through the existing
interface of their container/sup Porting framework. For example the Tomcat
servlet container presents a DBCP DataSource as a JNDI DataSource. James (Java
Apache Mail Enterprise Server) has integrated DBCP into the Avalon framework. A
Avalon-style DataSource is created by wrapping the DBCP implementation. The
pooling logic of DBCP and the configuration found in Avalon ' s Excalibur code are
What was needed to create I ntegrated reliable DataSource.

After reading the explanation, in fact, because the drivermanagerdatasource to establish a connection is as long as there is a connection to create a new connection, there is no connection pool role. It will be better to change to the following open source connection pool.
<bean id= "myDataSource" class= "Org.apache.commons.dbcp.BasicDataSource" destroy-method= "Close" >
<property name= "Driverclassname" >
<value>org.hsqldb.jdbcDriver</value>
</property>
<property name= "url" >
<value>jdbc:hsqldb:hsql://localhost:9001</value>
</property>
<property name= "username" >
<value>sa</value>
</property>
<property name= "Password" >
<value></value>
</property>
</bean>

Test pass, problem elimination, if no search engine to find the answer will not solve the problem so quickly.