Hi Laird,
Great questions! Ones that I know I had when setting these up. My understanding, based on documentation, official and blogs/SO/etc) is that ConnectionPoolDataSource extends DataSource and both can provide pooling to the end client.
In the case of DataSource, if the client uses an app server like Glassfish, you will be leveraging connection pooling provided by the app server.
In the case of ConnectionPooledDataSource you can use connection pooling provided by the driver impl you are using.
For Glassfish, and I know your SO question specifically said you weren't interested in specific cases, I follow the Oracle documentation here [1] for the specific driver I am using.
Notice in the case of Oracle it recommends choosing one of the following:
oracle.jdbc.pool.OracleDataSource
oracle.jdbc.xa.client.OracleXADataSource
I may be way off base here since I haven't looked at the GF code but I think that if you were to combine javax.sql.DataSource and oracle.jdbc.pool.OracleDataSource you would get GF supplied connection pooling. If you used ConnectionPooledDataSource the GF connection pooling for that connection pool could leverage Oracle driver based connection pooling presumably via Additional Properties you add yourself assuming GF supports doing so. I haven't seen any specific documentation on this so I may be off base here.
-Noah
[1] -
http://docs.oracle.com/cd/E26576_01/doc.312/e24928/jdbc.htm#ghatb
On Oct 11, 2012, at 6:06 PM, Laird Nelson <ljnelson_at_gmail.com> wrote:
> On Thu, Oct 11, 2012 at 2:45 PM, Marina Vatkina <marina.vatkina_at_oracle.com> wrote:
> I can answer the XA vs. non-XA part: non-XA resource commit is faster, and if it's a single non-XA resource in a transaction, GF doesn't even start the XA parts. But (of course) you can have only 1 non-XA resource in a transaction, and if you have 2 resources, and the resource or the server crashes (and tx recovery on startup is enabled) the non-XA resource cannot be recovered.
>
> Sure; XA is a special case for sure. In the non-XA case: I'm more trying to figure out why on earth you would ever NOT pick javax.sql.ConnectionPoolDataSource wherever it is offered to you at setup time? Is there a valid case?
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>