Note, one of the reasons for the behavior that you are seeing is that prior to 4.0.5, JBoss/JCA validated a connection prior to removing it from the pool for *each* getConnection attempt. As a result, the entire pool of connections had to be exhausted prior to attempting to obtain a new connection. This is the 'slow' failover you are seeing being that every connection has to be checked. With 4.0.5 background connection validation has been added where connection validation occurs in a background thread. As a result, connection validation for getConnection() can be disabled. Enabling background validation casues the validator to run and periodically removing invalid connections from the pool. While this does not address your problem specifically, choosing background validation can give you the option to disable the validate on match behavior. The issue in destroying the entire pool when a validation error occurs is that the condition may be temporary (ie network glitch, transient DB failure). Destroying the entire pool when this happens can ultimately become quite expensive. The purge policy discussed earlier will destroy the entire pool during a connection *failure*, not on validation. Have you considered setting the socketTimeout or experimenting with the other JDBC level properties to see if you can get the wait time down? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986028#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...