"[EMAIL PROTECTED]" wrote : What does this change actually do? It just seems to create a new connection and store it in threadlocal when the cacheloader is constructed, and that's it. | | So all it does is store a conn for a particular thread (the one that starts the cache). Other threads will still have to call getConnection() each time with a prepare(). | | Am I missing something, how does this result in being able to deal with capacity better?
Correct, note that it also enforces setting autocommit off. I am only fleetingly familiar with this code base - however I cannot deny the evidence of the tests. I can (now) successfully run up to 50,000 stores without issue. This does in fact seem to address the issue. Perhaps you can identify the full reason as to why. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977343#3977343 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977343 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
