db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: DataSource class hierarchy in client
Date Mon, 02 May 2005 23:55:41 GMT
David Jencks wrote:

> So that XADataSource does not implement DataSource.  I have yet to see a
> coherent explanation of what XADataSource is for and how it relates to
> connection pooling and application server transaction management, so I
> doubt most casual users have either.  If your XADataSource implements
> DataSource most non-expert users will think, "I'll just get my
> connection from XADataSource and I will have  XA and connection pooling"
> even though they are operating outside an environment that supports either.

I agree this is a confusing area in the JDBC spec.

Casual or non-expert users should not be using XADataSource or
ConnectionPoolDataSource interfaces, applications should always be
obtaining connections through the DataSource interface.

Extract from section 12.2 of JDBC 3.0 spec

"There is some similarity between ConnectionPoolDataSource objects and
XADataSource objects in that they are both implemented below a
DataSource layer that is visible to the JDBC application."

Also see the code examples in 12.2 and 12.3 for how application servers
handle this.

So with the current implementations I see

 -- slight risk for confusion either in calling the wrong method or
reading too much into the fact that an XADataSource implements DataSource.

 -- slight benefit in that you can use the same object with the same
property settings to see if a simple direct connection to the database
works if there are problems getting XA or pooled connections to work.

+0 to remove DataSource support from the client's XA and pooling data
source implementations.

Dan.


Mime
View raw message