The problem is this, when running the finder, if it uses the ReadAheadCache, it uses addFinderResults(). That method is synchronized, and, the way the system is coded, there is only one ReadAheadCache instance per CMP bean-type. So...there's this significant bottleneck when running multiple threads against the same bean.... This *clearly* can not be good. Now, I wasn't entirely sure on why there is only a single ReadAheadCache per bean-type. The read-ahead data itself is stored in the entity transaction cache. However, the paging data is stored in a single cache across all transactions. It is the management of this paging data that led to marking the method(s) synchronized on ReadAheadCache. Now, maybe there is a good reason for only having one paging cache for the whole system, I'm not sure. However, it MUST not be synchronized. It really causes problems if you have finders that return lots of results.... So...in order to remedy this, I modified JDBCStoreManager so that the getReadAheadCache() method returns different ReadAheadCache instances per transaction. I don't know if this will cause some subtler issue that I can't see, but...it certainly removes an INCREDIBLY significant bottleneck from the system. Maybe one of JBoss's developers would like to come up with a better fix? but this does seem to remedy the problem for now. As per my last post, I can't get the attach files to work when posting a large message, so the source will be attached to a follow-up post
