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.
