Delete a folder directory contains a lot of documents when the error

Today, when testing the file synchronization function, colleagues found that when you delete a folder directory, which contains a lot of documents in the report:

caused By:org.apache.commons.dbcp.SQLNestedException:Cannot get a connection, pool exhausted

At Org.apache.commons.dbcp.PoolingDataSource.getConnection (poolingdatasource.java:103)

At Org.apache.commons.dbcp.BasicDataSource.getConnection (basicdatasource.java:540)

At Org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.getConnection ( LOCALDATASOURCECONNECTIONPROVIDER.JAVA:81)

At Org.hibernate.jdbc.ConnectionManager.openConnection (connectionmanager.java:423)

... 154 more

caused by:java.util.NoSuchElementException:Timeout waiting for idle object

At Org.apache.commons.pool.impl.GenericObjectPool.borrowObject (genericobjectpool.java:756)

At Org.apache.commons.dbcp.AbandonedObjectPool.borrowObject (abandonedobjectpool.java:74)

At Org.apache.commons.dbcp.PoolingDataSource.getConnection (poolingdatasource.java:95)

... 157 more

2010-3-11 9:34:40 Org.apache.catalina.core.ApplicationContext Log

Info: org.springframework.jdbc.CannotGetJdbcConnectionException:Could not get JDBC Connection; Nested exception is org.apache.commons.dbcp.SQLNestedException:Cannot get a connection, pool exhausted

[DataManager] ERROR 2010-03-11 09:34:41,859 [http-8080-2] jdbcexceptionreporter.logexceptions (78) | Cannot get a connection, pool exhausted

[DataManager] ERROR 2010-03-11 09:34:41,859 [http-8080-2] jdbcexceptionreporter.logexceptions (78) | Cannot get a connection, pool exhausted

Org.hibernate.exception.GenericJDBCException:Cannot Open Connection

......

At first glance Org.apache.commons.dbcp.SQLNestedException:Cannot get a connection, pool exhausted know that the connection pool has been depleted.

Thought it wouldn't be in the process of deletion, the timer has already started the indexing process, because the number of threads does not control the connection pool is depleted?

But see the colleague's test directory below the number of pieces is not much, all is the picture, probably also has thirty or forty. But the index is not, usually index the entire Database Document table index then the number is much larger than here.

Online Search:

A, cannot get a connection, pool exhausted solution

Turn from: http://chivas2008.blogbus.com/logs/28735149.html

There are 3 solutions.

1 Reboot your Server

2 in Content.xml, set the maxactive to zero, or increase its value

3 properly shut down in your program connections here is a note to write down the statement in the Finally, if you write in try{} in the exception can not be properly closed.

To be like this.

catch (SQLException e) {

/** Exception Handling **/

finally {

try {

if (stmt!= null)

Stmt.close ();

if (dbconnection!= null)

Dbconnection.close ();

catch (SQLException e) {

/** Exception Handling **/

}

}

Of course these 3 methods in the first two can not fundamentally solve your problem, so still want to study your program, be sure to put the finished connection back into the pool.

1 Problem description

The Web program was fast when Tomcat was just beginning to run, but after a while it was found to be slow.

Check the log output and find the exception as follows:

Org.apache.commons.dbcp.SQLNestedException:Cannot get a connection, pool exhausted, cause:

Java.util.NoSuchElementException:Timeout Waiting for idle object

It is also found in SQL Server Profiler that every time an SQL statement executes, a audit login event is generated and the statement is executed

Audit Logout event. Shows that each tomcat is reopened for a new connection.

2 Problem Solving

Tomcat's data source definition provides three parameters:

A. If set to true Tomcat automatically checks for recovery reuse and does not have a properly closed connection. (default is False)

<parameter>

<name>removeAbandoned</name>

<value>true</value>

</parameter>

B. Set the connection that is considered to be discarded in the number of seconds it is to be used for recovery.

<parameter>

<name>removeAbandonedTimeout</name>

<value>60</value>

</parameter>

C. Output recycled log, you can print out the exception in detail so that there was a leak

<parameter>

<name>logAbandoned</name>

<value>true</value>

</parameter>

B, Timeout waiting for idle object

Turn from: http://203.208.37.132/search?q=cache:9TmBcAJrYhQJ:jiangzi87.blog.ccidnet.com/blog.php%3Fdo%3Dshowone% 26itemid%3d474468%26typ%3dblog+java.util.nosuchelementexception:+timeout+waiting+for+idle+object&cd=5& Hl=zh-cn&ct=clnk&gl=cn&st_usg=alhdy2-dzrxen0j7d6mj0shp7txcjwyumq

1, request too large error

In our application system, some users are reflected in filling in the application form, sometimes the request too large error, resulting in the operation failed. The reason is: The user fills in the application form. We'll put a certain amount of time Keep the data in your cookies. If the cookie is too large, it will cause the request too large error, remove cookies, the problem can be solved.

2, Timeout waiting for idle object error

Org.apache.commons.dbcp.SQLNestedException:Cannot get a connection, pool exhausted, cause:

Java.util.NoSuchElementException:Timeout Waiting for idle object

is because the connection is not closed, causing other connections to connect to this old connection. Cause an error

Check if the database connection is not turned off

When I see the part of the red shown in a, this parameter is really important for finding the reason. First look at the above error really let me confused, then configure this parameter, and then run the console error information more clearly, from the error message I found the operation of the function there are two local connection pool leakage problem:

At Com.xxx.action.DoccatalogAction.getDocCatalogListByCatCode (doccatalogaction.java:1178)

At Com.xxx.organization.dao.hibernate.UserHibernateDAOBean.getUserByName (userhibernatedaobean.java:54)

At Com.xxx.doc.desktopapp.action.DesktopAppAction.removeAllDataByCategoryList (desktopappaction.java:564)

You can tell which method is in, and which line of code has a connection pool leak problem.

"Cause":

It was really a colleague. The database-related connection to session,connection,statement, etc., is not released in the code.

"Workaround":

1, for the session of the part of all add

Avoid the connection pool exhaustion caused by not releasing the connection

Session session = This.getsession ();

try{

Execute code ...

}finally{

This.releasesession (session);

}

2. For database connection

Session session = Listhelper.getsessionfactory (). Opensession ();

Connection cnn = NULL;

Statement state = null;

ResultSet rs = null;

try{

CNN = Session.connection ();

State = Cnn.createstatement (

Resultset.type_scroll_insensitive,

RESULTSET.CONCUR_READ_ONLY);

String strsql= "";

strsql+= "Select d.* from Tb_datapriv_grant G, Tb_datapriv D where g.member_id= '" +userid+ "";

rs = State.executequery (strSQL),//Query directory Users have permissions

......

}finally{

Turn off RS

if (null!=rs) {

Rs.close ();

rs = null;

}

Close State

if (null!=state) {

State.close ();

state = null;

}

Turn off CNN

if (NULL!=CNN) {

Cnn.close ();

CNN = NULL;

}

Close session

if (null!=session) {

Session.close ();

session = NULL;

}

}

Of course, the method of getting session and releasing session in your project is not the same as mine, because there are some kinds of methods that we can encapsulate. But the same is sure to remember to release.