db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: DataSource class hierarchy in client
Date Tue, 03 May 2005 00:42:07 GMT

On May 2, 2005, at 4:55 PM, Daniel John Debrunner wrote:

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

After some thought I can't imagine a scenario in which this is a 
plausible action to take.  Could you elaborate?  From your comments 
above I think we agree that no application program will be using 
XADataSource, but instead a DataSource implementation supplied by a 
framework or application server.  Since the application program never 
sees the XADataSource, how would it try to get a Connection object from 
it?  Since XADataSource does not extend DataSource, a connection 
management framework would not try to get a Connection from an 

david jencks

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

View raw message