I was trying to use MySQL Connector/J-s ConnectionPoolDataSource implementation in JBOSS EAP 6.1 (also checked out WildFly, and it seems to have the same issues), and I found that it is impossible.

There are a number of issues that I encountered, that make it impossible

1. Configuration

The IronJacamar JCA Implementation that is in WildFly/EAP always prefers the java.sql.Driver interface configured over the DataSource interface configured.

Connector/J jar advertises its java.sql.Driver interface through META-INF/services, and which IronJacamar automagically loads into its configuration (as it should), and because it prefers java.sql.Driver over DataSource, it will always use the Driver interface. Nothing I tried (sort of deleting the META-INF/services directory from the driver jar) could convince IronJacamar to use the DataSource interface over the java.sql.Driver interface, and after checking the sources, it seems that it is actually impossible to do.

I think that is quite obviously a bug, and should be fixed. The driver defined in META-INF/services should only be used as a fallback, if there is no Driver, nor DataSource defined in the driver/db definition.

2. Lack of ConnectionPoolDataSource support

IronJacamar does not support the jdbc ConnectionPoolDataSource interface. In fact, the only places where the ConnectionPoolDataSource string appears in the sources is in the .xsd definition, where it says that it accepts ConnectionPoolDataSource classes in the driver definition. It is quite misleading, as while it may accept them, it uses them as a standard DataSource (the ancestor of ConnectionPoolDataSource).

As far as I understand (from reading the docs, and checking out the Mysql Connector/J), the advantage of using the ConnectionPoolDataSource is twofold. On one hand it provides a convinient way to manage the handling of the connection pool, on the other hand (at least in the case of mysql) it performs a re-initialization of the reused connection when handing it out, so that it is a known initialized state.

Now, all this functionality is already available in IronJacamar, it has its ow pooling implementation using the java.sql.Driver interface, and you can define queries to run before getting, and after returning the connection to the pool, but it seems to me that using the knowledge embedded in the driver about resetting the connection would be a more elegant (and possibly faster) way.

I'd like to know why IronJacamar ignores the ConnectionPoolDataSource interface.

Is it flawed in some way ?

Are the implementations in drivers buggy ?

Is it simply not seen as having added value over the java.sql.Driver based pooling implementation?

I may be interested in taking a shot at fixing issue No1, and implementing ConnectionPoolDataSource support, if it is deemed worthwile.