Performance of iBATIS

Lock occurs at com.ibatis.common.beans.ClassInfo#getInstance in case of cacheEnabled = true

In heavy traffic , lock occurs at com.ibatis.common.beans.ClassInfo#getInstance in case of cacheEnabled = true. It seems to be happend because of "double synchronized"

• https://issues.apache.org/jira/browse/IBATIS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683961

The following is interesting article related to the above issue.

• http://www.kaigrabfelder.de/en/2009/05/01/concurrency_vs_synchronization.html

The above article says that we'd better use java.util.concurrent.ConcurrentHashMap (in JDK 5) rather than Collections.synchronizedMap, Hashtable or synchronized block.

Here is another article worth reading.

• http://www.sun.com/bigadmin/features/articles/jvm_tuning_study.jsp#Ibatis

Race conditions in Throttle lead to thread blockage popping items from ThrottledPools under stress.

com.ibatis.common.util.Throttle seems to be a mechanism for iBATIS to control concurrent load, but causes few problems. Throttle is removed entirely in 2.3.1.

• https://issues.apache.org/jira/browse/IBATIS-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491675

The test I involved showed 20% enhancement of throughput under high congestion after removing wait and notify from com.ibatis.common.util.Throttle and applying ConcurrentHashMap to com.ibatis.common.beans.ClassInfo.getInstance(). The tested application was stock trading application which had about 12,000 lines in all and consisted of 8 stateless local session beans using iBATIS 2.3 for data access. The application had about 12,000 lines. The application was on a IBM machine which had 10 PowerPC POWER6 CPUs and 16GB RAM. The stress test showed 2,400TPS before and 2,900TPS after the fixing.