Hi everyone. I've been wanting to eliminate those pesky maxSessions, maxTransaction and maxRequest settings for a long time. Mostly because they're abused, misused and misunderstood -- which is my fault. I have never explained them well. Part of the reason is that there's no good explanation for them except: it made sense at the time and they were put in place entirely for performance reasons.
However, they are complicated and may actually reduce performance on modern VMs, drivers and databases. History: when we were doing the JPetStore benchmarks (the daddy of iBATIS), we noticed that under load regular JDBC (driver + database + app server) did a poor job of dealing with too many requests. We found that if we created an artificial (yet configurable) bottleneck within the application, it actually performed better. This was mostly due to leaving database resources more free to deal with an acceptable level of concurrency instead of spending most of its time context switching to deal with requests. That said, most people will never use these settings, those who do will likely make things worse and modern databases and drivers should be better at this. So, my recommendation is to get rid of the settings and stop pooling these resources. Instead, sessions, transactions and requests will be created as needed. Two caveats: 1) If you don't properly close transactions now, you may never know. This shouldn't create a memory leak (which would actually be nice because at least you'd know). But instead your database logs will report that connections aren't being closed and transactions aren't being ended....I'm fine with this. The problem is reported in the appropriate place. Today if you don't close transactions properly, you could run out of sessions/requests/transactions and hence get a deadlock in the application (which we have had reports of). I personally prefer the app to just bomb when there's a bug. 2) Your application may intrinsicly perform better or worse after this change. We don't know. I'd like to avoid having a "setting" to enable or disable these things. My bet is that most applications will perform better -- even just for the elimination of synchronization code around the pooling of these things. The few applications that perform worse can be dealt with on a case-by-case basis. I really do expect them to be rare. Benefits: The three areas in iBATIS architecture that use synchronized code are: * ClassInfo (per Class) -- REQUIRED * Session, Request, Transaction (per pool) -- REQUIRED * Caching (per CacheModel) -- OPTIONAL * Lazy Loading (per Loader) -- OPTIONAL * Auto-Result Mapping (per ResultMap) -- OPTIONAL * Logging (per Logger) -- OPTIONAL By far THE most called are the session/request/transaction pools. Everything else is either rarely called (classinfo) or optional (caching/logging etc.). So I think we could significantly reduce the theoretical bottlenecks in highly concurrent applications and move the responsibility to the database and driver for dealing with this stuff. Thoughts? Clinton
