How critical is your app? What's the peak load? If this is a serious enterprise app, I'd consider using alternate data source:
* From Developer Guide (I'm sure you've seen that) * Note!: SimpleDataSource is quite convenient, efficient and effective. However, for large enterprise or mission critical applications, it is recommended that you use an enterprise level DataSource implementation (such as those that come with App Servers and commercial O/R mapping tools). Reducing Pool.MaximumCheckoutTime may help to narrow down the issue, as checked out connections will be eligible for pool sooner than you may have specified currently. Also, advising your DAOs with something like Spring AOP or AspectJ to log meaningful usage statistics may help to provide some verbosity to how your DAO layer is utilized by your web app, especially in regards to the load it may be experiencing at different times. In my opinion, the most straightforward way to attack the problem is to try a different data source implementation. For many years I've been very successfull with Apache commons DBCP, and given the warning about SimpleDataSource usage in iBatis documentation I'd definitely try alternate implementation before investing too much time and effort on what may be a dead-end. In regards to settings, your suggestion to try higher maxRequests is what I would also try. I'm not sure if reducing max transactions will make much difference, because your db server isn't likely to experiencing half of that. You have max transactions at 64 but it probably never even reaches that limit. One last thing - although it may be an overkill - is to enable iBatis debugging via in your logger, which may provide some interesting hints. That however, may come at cost of significant slowdown to your app (depending on the load which I don't know what it is). Regards, -adam On 9/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Our J2SE webapp using iBatis with SimpleDataSource running in Apache Tomcat > occasionally starts to hang. It hits the roof of max. Nr. of threads and > looking at the thread dump, there are many threads that seem blocked trying > to get and return(!) connections from and to the pool: > > "TP-Processor406" daemon prio=10 tid=0x005fbc00 nid=0xda4 waiting for monitor > entry [0x7ce7f000..0x7ce81788] > java.lang.Thread.State: BLOCKED (on object monitor) > at > com.ibatis.common.jdbc.SimpleDataSource.pushConnection(SimpleDataSource.java:521) > - waiting to lock <0x9e9d37f0> (a java.lang.Object) > at > com.ibatis.common.jdbc.SimpleDataSource.access$100(SimpleDataSource.java:52) > at > com.ibatis.common.jdbc.SimpleDataSource$SimplePooledConnection.invoke(SimpleDataSource.java:954) > at $Proxy21.close(Unknown Source) > [...] > > It almost looks to me as if SimpleDataSource blocks threads from returning > connections to the pool, while other threads are trying to get connections > from it - some kind of deadlock scenario? > > Assuming that my observation is wrong, I wonder if our configuration is good. > We currently have: > > iBatis settings > > maxRequests="128" > maxSessions="64" > maxTransactions="64" > > and datasource settings > > maxActive=50 > maxIdle=15 > > Isn't maxTransactions too high? Besides the rules pointed out in the > documentation, are there rules on how these settings should relate to the > datasource settings? Something like maxActive should be at least maxSessions > or something like that? > > Would these settings be any good? > > maxRequests="320" > maxSessions="64" > maxTransactions="32" > > Torsten >
