That sounds like a programming issue. Usually this happens when transactions are not ended properly, especially in the event of an exception. Can you confirm that ALL (no exceptions) of your ibatis code follows one of two paradigms:
Automatic Transaction:
Object something = sqlMapClient.queryForObject();
Programmatic Transaction:
try {
sqlMapClient.startTransaction();
sqlMapClient.insert(something);
sqlMapClient.update(somethingElse);
sqlMapClient.delete(anotherThing);
sqlMapClient.commitTransaction();
} finally {
sqlMapClient.endTransaction();
}
If you're using sessions and a custom connection (i.e. EXTERNAL tranasaction manager type), you should be sure to close them explicitly and within a finally block.
SqlMapSession session = sqlMapClient.openSession(connection);
try {
sqlMapClient.insert(something);
sqlMapClient.update(somethingElse);
sqlMapClient.delete(anotherThing);
} finally {
session.close();
}
The problem you describe makes me think sessions are not being closed somewhere.
Also whatch for usages of sqlMapClient.setUserConnection(connection). If you use that anywhere in your code, you have to explicitly "unset" the user connection by calling sqlMapClient.setUserConnection.(null). This approach is deprecated in favour of using openSession().
Cheers,
Clinton
On 8/15/05, Adam Gugliciello <[EMAIL PROTECTED]> wrote:
we're throwing 900 VU at it, with a 5 second sleep time between requests. Of this, about 1/6th ever hits ibatis. The boxen: client (.NET talking to java via Webservices), middle tier (java application using RPC to bridge between axis and the class where ibatis lives) and the db, all show <35% usage on resources. The issue seems to be that long after we stop the test, the session pool is still throttled, and there are a number of requests left hanging out forever waiting for their lock to release, despite the fact that no one is even executing right now, and that the queued sessions should be getting released. I have set the max sessions to 128 for both boxes in the cluster amd will see if it stops blocking up under this load.
From: Clinton Begin [mailto:[EMAIL PROTECTED]]
Sent: Mon 8/15/05 2:06 PM
To: [email protected]
Subject: Re: ThrottledPool hanging
Well, blocking is what the throttled pool is intended to do. It should only block when the pool is exhausted though. Blocking alone isn't the problem. Blocking is a good thing when it is potentially releaving excessive strain on a particular resource (say a database). So ThrottledPool is meant to block.
If you have incredible infrastructure, you could try increasing the maximum sessions to some enormous number.
BTW: Don't test using a for-loop with no idle time. Only test using a reasonably realistic user profile w/page timeouts. There's a HUGE difference between enterprise performance and for-loop execution times.
Cheers,
Clinton
On 8/15/05, Adam Gugliciello <[EMAIL PROTECTED]> wrote:FYI: The execution code looks like, not that according to the dump it A) ever gets here or B) are there any running threads in the pool which should be holding the synchronization object:
private static interface SqlMapTemplate
{
public void execute(SqlMapClient client) throws SQLException;
}
executeSqlMapTemplate(new SqlMapTemplate()
{
public void execute(SqlMapClient client) throws SQLException
{
Map parameters = new HashMap();
parameters.put("erightsUserId", new Integer(erightsUserId));
parameters.put("groupingName", groupName);
parameters.put("templateName", templateName);
_log.debug("called, uid:" + erightsUserId + ", grp:" + groupName + ", template:" + templateName);
client.queryWithRowHandler("questionFindByGroup",
parameters,
new RowHandler()
{
public void handleRow(Object rowData)
{
QuestionRow row = (QuestionRow) rowData;
try
{
_log.debug("Row found:" + row);
doc.handleRow(row);
}
catch (IOException e)
{
String message =
"Unable to write: "
+ e.getClass().getName()
+ " : "
+ e.getMessage();
_log.error(message, e);
throw new RuntimeException(message);
}
}
});
}
});
________________________________
From: Adam Gugliciello [mailto:[EMAIL PROTECTED]]
Sent: Mon 8/15/05 1:31 PM
To: "<user-java"@ibatis.apache.org
Subject: RE: ThrottledPool hanging
It doesn't actually take a minute to get the connection, it's just a safe and reasonable timeout.
________________________________
From: Clinton Begin [mailto: [EMAIL PROTECTED]]
Sent: Mon 8/15/05 1:19 PM
To: [email protected]
Subject: Re: FW:
Why does it take a minute to get a connection? With a connection pool, it should literally be milliseconds....
Clinton
On 8/15/05, Adam Gugliciello <[EMAIL PROTECTED]> wrote:
Under a heavy sustained load, the sqlmaps ThrottledPool seems to start to bind, the the vast majority of them binding up and blocking waiting to build a new session, and stay blocked long after the fact, even days after the request has been abandoned. Any help would be appreciated, and I am attaching a thread dump.
My code looks like:
private void executeSqlMapTemplate(SqlMapTemplate t) throws SQLException
{
final Connection c =
this._dbPool.borrowConnection("QuestionnaireCustomerApi",
1 * 60 * 1000l); // Waits a minute for a connection
if (c == null)
{
throw new IllegalStateException("Unable to retrieve JDBC Connection from db pool.");
}
try
{
SqlMapSession sess=this.sqlMapClient.openSession(c);
t.execute(this.sqlMapClient);
sess.close();
}
finally
{
this._dbPool.returnConnection(c);
}
}
