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 Tue, 03 May 2005 21:01:25 GMT
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.


View raw message