db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shreyas Kaushik <Shreyas.Kaus...@Sun.COM>
Subject Re: DataSource class hierarchy in client
Date Tue, 03 May 2005 04:11:28 GMT


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

Mime
View raw message