I've removed all thread throttling from iBATIS. It was causing a great deal of confusing and people complained about performance. The thread throttling was quite advanced and had a lot of scalability testing behind it, it was able to hide a lot of problems like this.
The downside is that you now have to make sure you're not throwing too much at your database. The way you've solved it is probably the way it should have been originally. iBATIS was hiding the problem for you, which was sometimes a feature, and other times a bug. At least now you know what's really going on... :-) That said, it's also possible that you're not closing your transactions properly. The thread throttling in past releases also did a good job of hiding that from you as well.. but now you'll start to see the database complain about such errors. Again, sometimes a feature, other times a bug. Clinton On Thu, Jul 17, 2008 at 9:55 AM, Michael Schall <[EMAIL PROTECTED]> wrote: > Production Environment: > We are using a JNDI datasource in WS 6.1 (fixpack 15) to connect to a DB2 > 9.1 (fixpack 2) database on a separate cluster. > > We recently upgraded our Java version of iBATIS after falling way behind > from 2.0.9 to the latest release 2.3.1. > > The dev and test environment showed no issues with the upgrade. > > When rolling out to production we started getting lock timeouts that would > bring the system down under heavy load. > > We did not recreate the JNDI datasource or replace any database drivers on > the WebSphere machines or make any configuration changes within DB2 (other > than new tables/columns) during the latest release. > > We first thought the default IsolationLevel had changed from "Cursor > Stability" to "Read Stability", but that is actually the default > IsolationLevel when connecting from WS to DB2 using JNDI. However, as a > troubleshooting step, we set the IsolationLevel within the JNDI datasource > to 2 (Cursor Stability), which is allowing our system to avoid the lock > timeouts. > > I have looked throught the change log and nothing seems to point to the > issue we are having. Any ideas on where our problem might be? > > Thanks for your time. > > Mike >
