David Jencks wrote: > > On May 2, 2005, at 4:55 PM, Daniel John Debrunner wrote:
>> 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. Your probably right. Derby might use this in its testing for the embedded driver, but it's probably of little value. I'm the same with the confusion issue, I don't really see a problem, the class implements both interfaces correctly and they are independent of each other. Dan.
