From derby-user-return-4244-apmail-db-derby-user-archive=db.apache.org@db.apache.org Mon May 15 22:51:46 2006 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 24505 invoked from network); 15 May 2006 22:51:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 May 2006 22:51:45 -0000 Received: (qmail 58280 invoked by uid 500); 15 May 2006 22:51:43 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 58160 invoked by uid 500); 15 May 2006 22:51:43 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 58138 invoked by uid 99); 15 May 2006 22:51:42 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 May 2006 15:51:42 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [192.18.42.249] (HELO nwkea-pix-1.sun.com) (192.18.42.249) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 May 2006 15:51:41 -0700 Received: from d1-sfbay-02.sun.com ([192.18.39.112]) by nwkea-pix-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k4FMpKba008597; Mon, 15 May 2006 15:51:20 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-02.sun.com by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IZB00701WT8A600@d1-sfbay-02.sun.com> (original mail from Richard.Hillegas@Sun.COM); Mon, 15 May 2006 15:51:20 -0700 (PDT) Received: from [129.150.25.72] by d1-sfbay-02.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IZB00LESWTK4L30@d1-sfbay-02.sun.com>; Mon, 15 May 2006 15:51:20 -0700 (PDT) Date: Mon, 15 May 2006 15:51:21 -0700 From: Rick Hillegas Subject: Re: Proposal to change Derby's public api for XADataSource and ConnectionPoolDataSource In-reply-to: <4468FB97.7050603@sbcglobal.net> Sender: Richard.Hillegas@Sun.COM To: Derby Discussion Cc: derby-dev@db.apache.org Message-id: <446905E9.8030905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <446399FC.1060004@sun.com> <4468FB97.7050603@sbcglobal.net> User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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. > > > 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. > > > > Kathey > > >