You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <Ri...@Sun.COM> on 2006/05/11 22:09:32 UTC
Proposal to change Derby's public api for XADataSource and
ConnectionPoolDataSource
Dear Derby users,
Please read this message if you work on an application server or in an
application layer which cares about distributed transactions and/or
pooled connections.
Right now the inheritance graph for Derby's DataSources does not mirror
the corresponding graph of interfaces in javax.sql. Derby's DataSources
are classes which you will find in Derby's published javadoc for the
package org.apache.derby.jdbc. In particular, Derby's XADataSources and
ConnectionPoolDataSources implement the DataSource interface. This is so
even though the javax.sql.XADataSource and
javax.sql.ConnectionPoolDataSource interfaces themselves do not extend
javax.sql.DataSource.
We believe this is confusing, particularly to developers who are trying
to build applications which easily port across different vendors' JDBC
implementations. We propose to rework the hierarchy of classes in
org.apache.derby.jdbc so that our XADataSources and
ConnectionPoolDataSources no longer implement javax.sql.DataSource. We
propose to expose this change in Derby 10.2.
However, we do not want to make this change if it will break existing
applications. Please let us know if you think this will break your app
server or other Derby-powered application.
Thanks,
-Rick
-----------------------------------------------------------------------------------
Here is a bit more detail on the problem. This is the inheritance graph
from javax.sql:
CommonDataSource
/ | \
XADataSource DataSource ConnectionPoolDataSource
Here is the corresponding 10.1 graph from org.apache.derby.jdbc:
ClientDataSource
/ \
ClientXADataSource ClientConnectionPoolDataSource
We propose the following 10.2 graph for org.apache.derby.jdbc
ClientBaseDataSource
/ | \
ClientXADataSource ClientDataSource ClientConnectionPoolDataSource
Re: Proposal to change Derby's public api for XADataSource and
ConnectionPoolDataSource
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks for forwarding this, Kathey.
Regards,
-Rick
Kathey Marsden wrote:
> Rick Hillegas wrote:
>
>> Dear Derby users,
>>
>> 0Please read this message if you work on an application server or in
>> an application layer which cares about distributed transactions
>> and/or pooled connections.
>>
>> Right now the inheritance graph for Derby's DataSources does not
>> mirror the corresponding graph of interfaces in javax.sql. Derby's
>> DataSources are classes which you will find in Derby's published
>> javadoc for the package org.apache.derby.jdbc. In particular, Derby's
>> XADataSources and ConnectionPoolDataSources implement the DataSource
>> interface. This is so even though the javax.sql.XADataSource and
>> javax.sql.ConnectionPoolDataSource interfaces themselves do not
>> extend javax.sql.DataSource.
>>
>> We believe this is confusing, particularly to developers who are
>> trying to build applications which easily port across different
>> vendors' JDBC implementations. We propose to rework the hierarchy of
>> classes in org.apache.derby.jdbc so that our XADataSources and
>> ConnectionPoolDataSources no longer implement javax.sql.DataSource.
>> We propose to expose this change in Derby 10.2.
>>
>> However, we do not want to make this change if it will break existing
>> applications. Please let us know if you think this will break your
>> app server or other Derby-powered application.
>>
> I got this feedback from someone supporting an app server.
>
> <quote>
> I think its a risky change if you ask me. You don't know if users
> already depend on such behavior. Also, not sure i understand the
> statement "We believe this is confusing, particularly to developers
> who are trying to build applications which easily port across
> different vendors' JDBC implementations." Can you explain more? BTW,
> Oracle does implement the javax.sql.DataSource, so you are not hte
> only one. DB2 doesn't though.
>
> We depend on having your PooledDS be instance of
> ConnnectionPoolDataSource and your XADS be instance of
> javax.sql.XADataSource and nothing else.
> Saying that however, i don't know what our stack products are doing
> with the Derby DataSources specially if they have special Derby logic,
> so my statement is only for our base.
> </quote>
>
>
> Kathey
>
>
>
Re: Proposal to change Derby's public api for XADataSource and
ConnectionPoolDataSource
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks for forwarding this, Kathey.
Regards,
-Rick
Kathey Marsden wrote:
> Rick Hillegas wrote:
>
>> Dear Derby users,
>>
>> 0Please read this message if you work on an application server or in
>> an application layer which cares about distributed transactions
>> and/or pooled connections.
>>
>> Right now the inheritance graph for Derby's DataSources does not
>> mirror the corresponding graph of interfaces in javax.sql. Derby's
>> DataSources are classes which you will find in Derby's published
>> javadoc for the package org.apache.derby.jdbc. In particular, Derby's
>> XADataSources and ConnectionPoolDataSources implement the DataSource
>> interface. This is so even though the javax.sql.XADataSource and
>> javax.sql.ConnectionPoolDataSource interfaces themselves do not
>> extend javax.sql.DataSource.
>>
>> We believe this is confusing, particularly to developers who are
>> trying to build applications which easily port across different
>> vendors' JDBC implementations. We propose to rework the hierarchy of
>> classes in org.apache.derby.jdbc so that our XADataSources and
>> ConnectionPoolDataSources no longer implement javax.sql.DataSource.
>> We propose to expose this change in Derby 10.2.
>>
>> However, we do not want to make this change if it will break existing
>> applications. Please let us know if you think this will break your
>> app server or other Derby-powered application.
>>
> I got this feedback from someone supporting an app server.
>
> <quote>
> I think its a risky change if you ask me. You don't know if users
> already depend on such behavior. Also, not sure i understand the
> statement "We believe this is confusing, particularly to developers
> who are trying to build applications which easily port across
> different vendors' JDBC implementations." Can you explain more? BTW,
> Oracle does implement the javax.sql.DataSource, so you are not hte
> only one. DB2 doesn't though.
>
> We depend on having your PooledDS be instance of
> ConnnectionPoolDataSource and your XADS be instance of
> javax.sql.XADataSource and nothing else.
> Saying that however, i don't know what our stack products are doing
> with the Derby DataSources specially if they have special Derby logic,
> so my statement is only for our base.
> </quote>
>
>
> Kathey
>
>
>
Re: Proposal to change Derby's public api for XADataSource and ConnectionPoolDataSource
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> Dear Derby users,
>
> 0Please read this message if you work on an application server or in
> an application layer which cares about distributed transactions and/or
> pooled connections.
>
> Right now the inheritance graph for Derby's DataSources does not
> mirror the corresponding graph of interfaces in javax.sql. Derby's
> DataSources are classes which you will find in Derby's published
> javadoc for the package org.apache.derby.jdbc. In particular, Derby's
> XADataSources and ConnectionPoolDataSources implement the DataSource
> interface. This is so even though the javax.sql.XADataSource and
> javax.sql.ConnectionPoolDataSource interfaces themselves do not extend
> javax.sql.DataSource.
>
> We believe this is confusing, particularly to developers who are
> trying to build applications which easily port across different
> vendors' JDBC implementations. We propose to rework the hierarchy of
> classes in org.apache.derby.jdbc so that our XADataSources and
> ConnectionPoolDataSources no longer implement javax.sql.DataSource. We
> propose to expose this change in Derby 10.2.
>
> However, we do not want to make this change if it will break existing
> applications. Please let us know if you think this will break your app
> server or other Derby-powered application.
>
I got this feedback from someone supporting an app server.
<quote>
I think its a risky change if you ask me. You don't know if users
already depend on such behavior. Also, not sure i understand the
statement "We believe this is confusing, particularly to developers who
are trying to build applications which easily port across different
vendors' JDBC implementations." Can you explain more? BTW, Oracle does
implement the javax.sql.DataSource, so you are not hte only one. DB2
doesn't though.
We depend on having your PooledDS be instance of
ConnnectionPoolDataSource and your XADS be instance of
javax.sql.XADataSource and nothing else.
Saying that however, i don't know what our stack products are doing
with the Derby DataSources specially if they have special Derby logic,
so my statement is only for our base.
</quote>
Kathey
Who are the product managers from Sun and IBM?
Posted by de...@segel.com.
Just out of curiosity,
Does anyone know who the product managers are from Sun or IBM?
Note: Yes Derby is Apache. However Sun has JavaDB and IBM has Cloudscape.
So who would be the product managers that can talk about these products?
TIA!
-Mike
Re: Proposal to change Derby's public api for XADataSource and
ConnectionPoolDataSource
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi,
It appears that you have made the appropriate change.
XADataSource is not a user API, and in fact isn't a kind-of
DataSource. It was misnamed (IMHO) from the beginning. An
XADataSource is a factory that produces XAConnections, which are not
Connections, but are chimeras (produced by an internal mating of an
XAResource and a Connection). You might want to see if Derby's
implementation also incorrectly has XAConnection extending Connection.
Craig
On May 11, 2006, at 1:09 PM, Rick Hillegas wrote:
> Dear Derby users,
>
> Please read this message if you work on an application server or in
> an application layer which cares about distributed transactions and/
> or pooled connections.
>
> Right now the inheritance graph for Derby's DataSources does not
> mirror the corresponding graph of interfaces in javax.sql. Derby's
> DataSources are classes which you will find in Derby's published
> javadoc for the package org.apache.derby.jdbc. In particular,
> Derby's XADataSources and ConnectionPoolDataSources implement the
> DataSource interface. This is so even though the
> javax.sql.XADataSource and javax.sql.ConnectionPoolDataSource
> interfaces themselves do not extend javax.sql.DataSource.
>
> We believe this is confusing, particularly to developers who are
> trying to build applications which easily port across different
> vendors' JDBC implementations. We propose to rework the hierarchy
> of classes in org.apache.derby.jdbc so that our XADataSources and
> ConnectionPoolDataSources no longer implement javax.sql.DataSource.
> We propose to expose this change in Derby 10.2.
>
> However, we do not want to make this change if it will break
> existing applications. Please let us know if you think this will
> break your app server or other Derby-powered application.
>
> Thanks,
> -Rick
>
>
> ----------------------------------------------------------------------
> -------------
>
> Here is a bit more detail on the problem. This is the inheritance
> graph from javax.sql:
>
> CommonDataSource
> / | \
> XADataSource DataSource ConnectionPoolDataSource
>
> Here is the corresponding 10.1 graph from org.apache.derby.jdbc:
>
> ClientDataSource
> / \
> ClientXADataSource ClientConnectionPoolDataSource
>
> We propose the following 10.2 graph for org.apache.derby.jdbc
>
> ClientBaseDataSource
> / | \
> ClientXADataSource ClientDataSource ClientConnectionPoolDataSource
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Proposal to change Derby's public api for XADataSource and
ConnectionPoolDataSource
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi,
It appears that you have made the appropriate change.
XADataSource is not a user API, and in fact isn't a kind-of
DataSource. It was misnamed (IMHO) from the beginning. An
XADataSource is a factory that produces XAConnections, which are not
Connections, but are chimeras (produced by an internal mating of an
XAResource and a Connection). You might want to see if Derby's
implementation also incorrectly has XAConnection extending Connection.
Craig
On May 11, 2006, at 1:09 PM, Rick Hillegas wrote:
> Dear Derby users,
>
> Please read this message if you work on an application server or in
> an application layer which cares about distributed transactions and/
> or pooled connections.
>
> Right now the inheritance graph for Derby's DataSources does not
> mirror the corresponding graph of interfaces in javax.sql. Derby's
> DataSources are classes which you will find in Derby's published
> javadoc for the package org.apache.derby.jdbc. In particular,
> Derby's XADataSources and ConnectionPoolDataSources implement the
> DataSource interface. This is so even though the
> javax.sql.XADataSource and javax.sql.ConnectionPoolDataSource
> interfaces themselves do not extend javax.sql.DataSource.
>
> We believe this is confusing, particularly to developers who are
> trying to build applications which easily port across different
> vendors' JDBC implementations. We propose to rework the hierarchy
> of classes in org.apache.derby.jdbc so that our XADataSources and
> ConnectionPoolDataSources no longer implement javax.sql.DataSource.
> We propose to expose this change in Derby 10.2.
>
> However, we do not want to make this change if it will break
> existing applications. Please let us know if you think this will
> break your app server or other Derby-powered application.
>
> Thanks,
> -Rick
>
>
> ----------------------------------------------------------------------
> -------------
>
> Here is a bit more detail on the problem. This is the inheritance
> graph from javax.sql:
>
> CommonDataSource
> / | \
> XADataSource DataSource ConnectionPoolDataSource
>
> Here is the corresponding 10.1 graph from org.apache.derby.jdbc:
>
> ClientDataSource
> / \
> ClientXADataSource ClientConnectionPoolDataSource
>
> We propose the following 10.2 graph for org.apache.derby.jdbc
>
> ClientBaseDataSource
> / | \
> ClientXADataSource ClientDataSource ClientConnectionPoolDataSource
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Proposal to change Derby's public api for XADataSource and ConnectionPoolDataSource
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> Dear Derby users,
>
> 0Please read this message if you work on an application server or in
> an application layer which cares about distributed transactions and/or
> pooled connections.
>
> Right now the inheritance graph for Derby's DataSources does not
> mirror the corresponding graph of interfaces in javax.sql. Derby's
> DataSources are classes which you will find in Derby's published
> javadoc for the package org.apache.derby.jdbc. In particular, Derby's
> XADataSources and ConnectionPoolDataSources implement the DataSource
> interface. This is so even though the javax.sql.XADataSource and
> javax.sql.ConnectionPoolDataSource interfaces themselves do not extend
> javax.sql.DataSource.
>
> We believe this is confusing, particularly to developers who are
> trying to build applications which easily port across different
> vendors' JDBC implementations. We propose to rework the hierarchy of
> classes in org.apache.derby.jdbc so that our XADataSources and
> ConnectionPoolDataSources no longer implement javax.sql.DataSource. We
> propose to expose this change in Derby 10.2.
>
> However, we do not want to make this change if it will break existing
> applications. Please let us know if you think this will break your app
> server or other Derby-powered application.
>
I got this feedback from someone supporting an app server.
<quote>
I think its a risky change if you ask me. You don't know if users
already depend on such behavior. Also, not sure i understand the
statement "We believe this is confusing, particularly to developers who
are trying to build applications which easily port across different
vendors' JDBC implementations." Can you explain more? BTW, Oracle does
implement the javax.sql.DataSource, so you are not hte only one. DB2
doesn't though.
We depend on having your PooledDS be instance of
ConnnectionPoolDataSource and your XADS be instance of
javax.sql.XADataSource and nothing else.
Saying that however, i don't know what our stack products are doing
with the Derby DataSources specially if they have special Derby logic,
so my statement is only for our base.
</quote>
Kathey