We only currently cover the case where a previous connection in the pool is invalid.

We don't cover the following cases:

* Somebody bounces the database server (or whatever the backend is)
making it unavailable for a few seconds, the pool will be drained of previous
connections (they are invalid) but then fail immediately to create a new one.

* The error is not raised by the pooling but by something in front of it
i.e. something in the connection manager causes the transient failure

e.g.
1) The original example is where the pool is flushed which causes a small
"window of opportunity" where a request is going through to the old subpool
that is being shutdown, rather than to the new subpool.
2) Other things in the connection manager like a transient failure in the
security login module that creates the subject

If you are really worried about only doing this for transient failures
we could create a subclass of ResourceException, e.g. TransientResourceException
and then have the places we think can be retried throw this exception,
* pool exhausted
* subpool shutdown
* etc.

We would then only do the retries for a TransientResourceException

Adrian, were you thinking about doing the allocate-retry / allocate-retry-wait-millis pair per XXX-datasource and thereby putting the configuration in jboss_ds_5_0.dtd or something else ?