On 07/11/2013 21:10, Christopher Schultz wrote: > Can you describe the effective difference between my > over-simplified description and what is implemented in commons-pool > (ignoring thread-fairness, which I'll admit is a very useful > feature)?
For starters, the relatively expensive validation process is outside the sync. Given where this thread started, that is a key point. Object creation, destruction, activation and deactivation are also all outside the syncs. Creation and destruction are very likely to be expensive as well (else why bother with a pool). The key difference is that pool uses syncs to give a thread permission to create an object, borrow an object, etc. Giving permission is very quick. The actual action is taken outside of the syncs as that is slow and expensive. You will still hit a synchronisation bottleneck with very high concurrency but I have a hard time believing most real world apps would actually get anywhere near the concurrency levels you need to reach to hit this bottleneck - if you use a recent version of Pool and DBCP. If you use the versions of 4 years ago then hitting the bottleneck is easy. You can use the unit tests in jdbc-pool to examine the sorts of concurrency levels you need to reach before you hit the bottleneck in DBCP+Pool. jdbc-pool and Pool2+DBCP2 remove the bottleneck entirely so in the unliekly event you have an app with that much concurrency, a bottleneck in the connection pool won't be an issue. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
