David Jencks wrote: > > 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 > XADataSource. > > thanks > david jencks When there is a call to DataSource's getConnection() method, this will happen on the framework's/app server's DataSource. If the underlying DataSource is a XADataSource, a call to getConnection() method gives out a XAConnection. This is wrapped as java.sql.Connection and returned back to the application. ~ Shreyas > >> >> +0 to remove DataSource support from the client's XA and pooling data >> source implementations. >> >> Dan. >> >