Skip to main content

Re: What is the official GlassFish position on which kind of DataSources to use?

No replies
ljnelson
Offline
Joined: 2003-08-04

On Thu, Oct 11, 2012 at 2:45 PM, Marina Vatkina
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

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
emailnbw
Offline
Joined: 2008-05-28

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 wrote:

> On Thu, Oct 11, 2012 at 2:45 PM, Marina Vatkina 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
>

ljnelson
Offline
Joined: 2003-08-04

On Thu, Oct 11, 2012 at 3:52 PM, Noah White wrote:

> 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.
>

And actually right there is a common misconception. Here's DataSource:
http://docs.oracle.com/javase/6/docs/api/javax/sql/DataSource.html

And here's ConnectionPoolDataSource:
http://docs.oracle.com/javase/6/docs/api/javax/sql/ConnectionPoolDataSou...

So the only common ancestor they share is CommonDataSource, which is an
obviously refactored base class:
http://docs.oracle.com/javase/6/docs/api/javax/sql/CommonDataSource.html

> 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.
>

And that's exactly the opposite of what another gentleman told me, and the
opposite of what the JDBC specification suggests in chapter 11 (one little
snippet: "In FIGURE 11-1, the JDBC driver provides an implementation
of ConnectionPoolDataSource
that the application server uses to build and manage the connection pool."
That suggests that GlassFish would manage the pool in both cases.). (This
is why I am bringing this up, and why I knew it would be a long road
towards getting an answer. :-))

> 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.
>

Yep, and I appreciate the response. Respectfully, however, that's why I
brought it up: it's still unclear and based on anecdote rather than
something we can all point to and say here, this is what THIS one does, and
this is what this OTHER one does.

Best,
Laird

--
http://about.me/lairdnelson

emailnbw
Offline
Joined: 2008-05-28

Hi Laird,

Great insights on this murky topic.

On Oct 11, 2012, at 8:07 PM, Laird Nelson wrote:

>
> 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.
>
> And that's exactly the opposite of what another gentleman told me, and the opposite of what the JDBC specification suggests in chapter 11 (one little snippet: "In FIGURE 11-1, the JDBC driver provides an implementation of ConnectionPoolDataSource that the application server uses to build and manage the connection pool." That suggests that GlassFish would manage the pool in both cases.). (This is why I am bringing this up, and why I knew it would be a long road towards getting an answer. :-))

That's the point I was trying to make. In the section below where I was discussing GF + Oracle I mentioned this behavior. In both cases you get a connection pool provided/managed by the AS but in the case of using ConnectionPoolDataSource you can leverage driver specific pooling functionality. Again this is just my take on the bits of things I've read but it would seem to agree with your snippet of the JDBC spec.

>
> 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.
>
> Yep, and I appreciate the response. Respectfully, however, that's why I brought it up: it's still unclear and based on anecdote rather than something we can all point to and say here, this is what THIS one does, and this is what this OTHER one does.

Agreed.

-Noah