Skip to main content

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

No replies
ljnelson
Offline
Joined: 2003-08-04

When setting up a connection pool, I can (if my driver supports it) choose
to expose the connections as javax.sql.DataSources,
javax.sql.ConnectionPoolDataSources or javax.sql.XADataSource.

After uncovering a state of affairs on the larger web that can best be
described as pure abject confusion punctuated here and there by misguided
folklore, I realized that no one really has the answer, and that it is
going to be an application-server-dependent issue, whether it was defined
as such or not.

GlassFish's own documentation makes no mention of ConnectionPoolDataSource,
but of course it's an option that the admin console lists:
http://docs.oracle.com/cd/E26576_01/doc.312/e24928/jdbc.htm#ggnfv

The documentation for javax.sql.ConnectionPoolDataSource does not provide a
hint as to whether it should be preferred or not in an application server
setting:
http://docs.oracle.com/javase/7/docs/api/javax/sql/ConnectionPoolDataSou...

The documentation for javax.sql.DataSource seems to imply, but does not
explicitly state, whether an implementor is pooling its connections
natively or not:
http://docs.oracle.com/javase/7/docs/api/javax/sql/DataSource.html

GlassFish then provides me the ability to pick between these two wildly
underspecified interfaces. How do I make the decision about which one to
pick, particularly if (as is common) my driver vendor implements both? Do
I err on the side of saying:

"Hmm, maybe my driver vendor knows best, so I will use (for example)
javax.sql.ConnectionPoolDataSource implemented by
com.informix.jdbcx.IfxConnectionPoolDataSource,
because I have a warm feeling that this will cause my vendor's
implementation of pooling to be used, I think...."

...or do I say:

"Oh, I see from the javax.sql.DataSource documentation, or at least I think
I do, that it is designed to hide whether pooling is happening or not, so I
will use (for example) javax.sql.DataSource implemented by
com.informix.jdbcx.IfxDataSource,
and rely on the application server to do pooling...hmm...or maybe it will
do some testing inside itself? and figure out if the implementation class
also implements javax.sql.ConnectionPoolDataSource, as is often the case?"

Then, suppose I need XA (which actually I do in some deployments). In that
case, surely--SURELY--I have to use javax.sql.XADataSource as my interface?
Or maybe this is another case where really I should use
javax.sql.DataSource, and then specify an implementation class that
implements XADataSource?

Here is a sample (one of hundreds) question that illustrates the fact that
no one really knows what's going on in this area:
http://stackoverflow.com/questions/6506859/datasource-or-connectionpoold...

Thanks for any help or guidance here.

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.
ljnelson
Offline
Joined: 2003-08-04

On Wed, Oct 10, 2012 at 11:22 AM, Laird Nelson wrote:

> When setting up a connection pool, I can (if my driver supports it) choose
> to expose the connections as javax.sql.DataSources,
> javax.sql.ConnectionPoolDataSources or javax.sql.XADataSource.
>
> After uncovering a state of affairs on the larger web that can best be
> described as pure abject confusion punctuated here and there by misguided
> folklore, I realized that no one really has the answer, and that it is
> going to be an application-server-dependent issue, whether it was defined
> as such or not.
>

My (still unanswered) StackOverflow question:
http://stackoverflow.com/questions/12826191/in-an-application-server-env...

It *seems* that one should always use ConnectionPoolDataSource (or
XADataSource) when one's driver supports it. It *seems* like at the
data-source-setup stage one should not deliberately expose one's data
source (little-d, little-s) as a javax.sql.DataSource if one has an
alternative. Is that correct?

Best,
Laird

--
http://about.me/lairdnelson