Addresses a shortcoming of the Universal Connection Pool pool creation logic in certain test scenarios

[ljnelson]

This PR is quite specialized.

This PR addresses a shortcoming in the Universal Connection Pool API when named connection pools are involved.

In the UCP API, when you call poolDataSource.getConnection(), a backing UniversalConnectionPool is created just-in-time, configured indirectly by a subset of configuration present on the PoolDataSource object. One part of that configuration is a Java Beans property called connectionPoolName.

Apparently UniversalConnectionPool instances are stored by name in a UniversalConnectionPoolManager singleton.

If you do not call setConnectionPoolName(String) on a PoolDataSource, a (hopefully guaranteed to be truly?) random name for the connection pool is generated internally by UCP, and your PoolDataSource's setConnectionPoolName(String) method is called with the new random name (none of this is documented, but unit tests show it to be true). In versions of Helidon prior to 4.0.6 this could result, in unit test scenarios, in dozens if not hundreds of UniversalConnectionPool instances all backing what is for all intents and purposes the same data source.

Helidon 4.0.6 tried to help this situation by checking to see if the connectionPoolName property was not set in configuration. If it was not, then the name defaulted to the data source name (so if you had a data source named fred, its backing connection pool would also be named fred, and you'd see that information in UCP logs and so on).

The problem is that it turns out there is no way to associate a PoolDataSource with a given connectionPoolName with an already-existing UniversalConnectionPool instance that has the same name (!). That is, when poolDataSource.getConnection() is called, a blind attempt at creating the backing connection pool is attempted (and fails), even if such a pool already exists, rather than an association operation. This scenario can crop up in certain user unit tests, apparently.

(It is a corollary of this that a user using only the PoolDataSource API, as instructed by the UCP documentation, has no way of knowing in advance whether the name she has selected for the connectionPoolName property is going to result in a SQLException or not.)

Prior to this change, the user has a couple of choices:

• destroy all connection pools "by hand" in her unit tests. This is probably the proper thing to do, but it is tedious.
• Proactively ensure that whatever connectionPoolName she selects for a given unit test is unique in all of her tests, resulting in possibly dozens if not hundreds of UniversalConnectionPool instances in her test suite (see above).

Neither option is particularly friendly.

This PR therefore amends the Helidon 4.0.7 behavior as follows:

• If a PoolDataSource configuration contains a value for connectionPoolName, no further magic behavior results. If that pool name happens to exist, tough luck. The UCP will fail in whatever way it fails, good or bad, right or wrong.
• If a PoolDataSource configuration does not contain a value for connectionPoolName:
  • the UCPBackedDataSourceExtension will now check to see if the data source name can be used as a pool name. This will only be the case if an equivalently-named connection pool does not already exist.
  • If such a named connection pool does not already exist, the extension will set the connectionPoolName property to the value of the data source name (as is currently done in 4.0.7).
  • If such a named connection pool does already exist, such as might happen in a unit test where the user has chosen not to destroy pools after each test for whatever reason, the extension will revert to 4.0.5 behavior and will not supply a name for the connectionPoolName property. This will result, as in 4.0.5, in at least two connection pools backing "the same" data source: the pre-existing named one, and the new one with a randomly generated name.

This description is approximately 35x longer than the actual PR so have a look.

[arjav-desai]

LGTM