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 Jeremy Boynes <jb...@apache.org> on 2005/05/02 22:38:51 UTC
DataSource class hierarchy in client
The class hierarchy the client DataSources is:
ClientBaseDataSource
|
+-- ClientDataSource
|
+-- ClientXADataSource
|
+-- ClientConnectionPoolDataSource
The three standard interfaces DataSource, ConnectionPoolDataSource and
XADataSource are not related to each other with different
get??Connection methods that return different classes.
I would like to propose refactoring this so that all three extend
ClientBaseDataSource directly which will mean moving some of the
properties from ClientDataSource down into the base class.
Any thoughts on why this should not be done?
--
Jeremy
Re: DataSource class hierarchy in client
Posted by Jeremy Boynes <jb...@apache.org>.
Daniel John Debrunner wrote:
> Jeremy Boynes wrote:
>
>>The class hierarchy the client DataSources is:
>>
>>ClientBaseDataSource
>> |
>> +-- ClientDataSource
>> |
>> +-- ClientXADataSource
>> |
>> +-- ClientConnectionPoolDataSource
>>
>>The three standard interfaces DataSource, ConnectionPoolDataSource and
>>XADataSource are not related to each other with different
>>get??Connection methods that return different classes.
>>
>>I would like to propose refactoring this so that all three extend
>>ClientBaseDataSource directly which will mean moving some of the
>>properties from ClientDataSource down into the base class.
>>
>>Any thoughts on why this should not be done?
>
>
> No, but what are the reasons it should be done?
>
As David Jencks pointed out, the interfaces being implemented don't
really bear any relationship to each other so I would say this cleans up
the model a bit. It also eliminates the chance of things like
erroneously calling e.g getConnection() on a ClientXADataSource.
--
Jeremy
Re: DataSource class hierarchy in client
Posted by Jeremy Boynes <jb...@apache.org>.
Shreyas Kaushik wrote:
>
>
> 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.
>
Not sure what you mean here.
The application code will always be interacting with a ConnectionFactory
provided by the appserver that happens to implement DataSource. A call
to getConnection() on this factory will be brokered by the
ConnectionManager long before the driver's implementations are used.
In other words, in a managed connection scenario such as an appserver
the application code can never call getConnection() on an XADataSource.
If the application is trying to do XA manually, then it will be getting
XAConnection's from the XADataSource, doing work on a (pooled)
connection obtained from the XAConnection and managing transactions
using its XAResource. Again it should never get a physical, non-XA
connection from the underlying implementation of XADataSource.
--
Jeremy
Re: DataSource class hierarchy in client
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
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.
>>
>
Re: DataSource class hierarchy in client
Posted by Daniel John Debrunner <dj...@debrunners.com>.
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.
Re: DataSource class hierarchy in client
Posted by David Jencks <dj...@gluecode.com>.
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
>
> +0 to remove DataSource support from the client's XA and pooling data
> source implementations.
>
> Dan.
>
Re: DataSource class hierarchy in client
Posted by Daniel John Debrunner <dj...@debrunners.com>.
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.
+0 to remove DataSource support from the client's XA and pooling data
source implementations.
Dan.
Re: DataSource class hierarchy in client
Posted by David Jencks <da...@yahoo.com>.
On May 2, 2005, at 3:08 PM, Daniel John Debrunner wrote:
> Jeremy Boynes wrote:
>> The class hierarchy the client DataSources is:
>>
>> ClientBaseDataSource
>> |
>> +-- ClientDataSource
>> |
>> +-- ClientXADataSource
>> |
>> +-- ClientConnectionPoolDataSource
>>
>> The three standard interfaces DataSource, ConnectionPoolDataSource and
>> XADataSource are not related to each other with different
>> get??Connection methods that return different classes.
>>
>> I would like to propose refactoring this so that all three extend
>> ClientBaseDataSource directly which will mean moving some of the
>> properties from ClientDataSource down into the base class.
>>
>> Any thoughts on why this should not be done?
>
> No, but what are the reasons it should be done?
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.
thanks
david jencks
>
> Dan.
>
Re: DataSource class hierarchy in client
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jeremy Boynes wrote:
> The class hierarchy the client DataSources is:
>
> ClientBaseDataSource
> |
> +-- ClientDataSource
> |
> +-- ClientXADataSource
> |
> +-- ClientConnectionPoolDataSource
>
> The three standard interfaces DataSource, ConnectionPoolDataSource and
> XADataSource are not related to each other with different
> get??Connection methods that return different classes.
>
> I would like to propose refactoring this so that all three extend
> ClientBaseDataSource directly which will mean moving some of the
> properties from ClientDataSource down into the base class.
>
> Any thoughts on why this should not be done?
No, but what are the reasons it should be done?
Dan.
Re: DataSource class hierarchy in client
Posted by Kathey Marsden <km...@sbcglobal.net>.
Jeremy Boynes wrote:
>
> The changes here are incremental and can be rolled back at any time.
>
>> I want to establish that the goals ...
>> are to make it more compatible with the embedded driver. I think that
>> is very important.
>>
>
> As I commented to Satheesh, I agree. There are differences there that
> will addressed incrementally as we go through this process.
>
OK, as long as embedded compatibility is the ultimate goal here I am a
happy camper and will lift my -1. In general, though, I would say it
would be good to consider our international developers and even those
who play on the weekend when making major changes.
Thanks
Kathey
Re: DataSource class hierarchy in client
Posted by Jeremy Boynes <jb...@apache.org>.
Kathey Marsden wrote:
> Jeremy Boynes wrote:
>
>
>>I am going to go through the client code and switch the usages to the
>>base class (which declares the methods being used) and then change the
>>hierarchy here as proposed.
>
>
> Hi Jeremy,
>
> I would vote -1 on the restructuring on the basis that I think that we
> should slow down here. We have people active in this project from
> around the world who deserve the opportunity to contribute their
> thoughts and I still see active discussion around this issue. I
> personally have concerns about embedded/client compatibility and in
> general would like to know what your thoughts are on embedded/client
> compatibility in your restructuring of the client.
>
We do not need to discuss this to death before implementing anything.
Going through this we are flushing out several issues which may not have
been obvious just from code inspection.
The changes here are incremental and can be rolled back at any time.
> I know that this time offers us a unique opportunity to change the
> behaviour of client, but I want to establish that the goals in doing so
> are to make it more compatible with the embedded driver. I think that
> is very important.
>
As I commented to Satheesh, I agree. There are differences there that
will addressed incrementally as we go through this process.
--
Jeremy
Re: DataSource class hierarchy in client
Posted by Kathey Marsden <km...@sbcglobal.net>.
Jeremy Boynes wrote:
>
> I am going to go through the client code and switch the usages to the
> base class (which declares the methods being used) and then change the
> hierarchy here as proposed.
Hi Jeremy,
I would vote -1 on the restructuring on the basis that I think that we
should slow down here. We have people active in this project from
around the world who deserve the opportunity to contribute their
thoughts and I still see active discussion around this issue. I
personally have concerns about embedded/client compatibility and in
general would like to know what your thoughts are on embedded/client
compatibility in your restructuring of the client.
I know that this time offers us a unique opportunity to change the
behaviour of client, but I want to establish that the goals in doing so
are to make it more compatible with the embedded driver. I think that
is very important.
Kathey
Re: DataSource class hierarchy in client
Posted by Jeremy Boynes <jb...@apache.org>.
Satheesh Bandaram wrote:
> I think the ClientBaseDataSource was not meant to be a public class. We
> tried to localize all public classes into the 'jdbc' package and use
> only the jdbc package to generate public javadoc. That is one of the
> reasons for putting all public tracing support in ClientDataSource.
>
> I would also like to match API with Embedded driver as much as possible.
> It would be real bad if applications need changes when using two
> different driver offerings of Derby. Your suggestions probably don't
> break this, but something to watch for. We tried to match Embedded
> behavior, unless it was deemed WRONG.
>
I agree that we want to the two to match up. Right now there are
differences e.g. in where methods are declared, what the properties are
and so forth. We should bring these into line.
In the embedded case, the base class is ReferenceableDataSource which is
in the public API package (jdbc). By that argument moving the properties
into ClientBaseDataSource is improving alignment and the next phase
should be to move it into the jdbc package in the client tree.
This does raise the question of whether there should just be one
implementation of the public API shared by client and embedded code,
just with different implementations behind it. Ultimately I would like
to get there.
--
Jeremy
Re: DataSource class hierarchy in client
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
I think the ClientBaseDataSource was not meant to be a public class. We
tried to localize all public classes into the 'jdbc' package and use
only the jdbc package to generate public javadoc. That is one of the
reasons for putting all public tracing support in ClientDataSource.
I would also like to match API with Embedded driver as much as possible.
It would be real bad if applications need changes when using two
different driver offerings of Derby. Your suggestions probably don't
break this, but something to watch for. We tried to match Embedded
behavior, unless it was deemed WRONG.
Satheesh
Jeremy Boynes wrote:
> Satheesh Bandaram wrote:
>
>> I suspect the class hierarchy has been made this way partly to match
>> Embedded driver. I am still thinking why the Embedded driver does this..
>>
>
> I don't know if it is relevant but most of the implementation in the
> client code uses ClientDataSource instances rather than the base class
> - in fact, the base class itself is never really used at all. I have a
> feeling there is some legacy leftover here.
>
> I am going to go through the client code and switch the usages to the
> base class (which declares the methods being used) and then change the
> hierarchy here as proposed.
>
> --
> Jeremy
>
>
>
Re: DataSource class hierarchy in client
Posted by Jeremy Boynes <jb...@apache.org>.
Satheesh Bandaram wrote:
> I suspect the class hierarchy has been made this way partly to match
> Embedded driver. I am still thinking why the Embedded driver does this..
>
I don't know if it is relevant but most of the implementation in the
client code uses ClientDataSource instances rather than the base class -
in fact, the base class itself is never really used at all. I have a
feeling there is some legacy leftover here.
I am going to go through the client code and switch the usages to the
base class (which declares the methods being used) and then change the
hierarchy here as proposed.
--
Jeremy
Re: DataSource class hierarchy in client
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
I suspect the class hierarchy has been made this way partly to match
Embedded driver. I am still thinking why the Embedded driver does this..
Satheesh
Jeremy Boynes wrote:
> The class hierarchy the client DataSources is:
>
> ClientBaseDataSource
> |
> +-- ClientDataSource
> |
> +-- ClientXADataSource
> |
> +-- ClientConnectionPoolDataSource
>
> The three standard interfaces DataSource, ConnectionPoolDataSource and
> XADataSource are not related to each other with different
> get??Connection methods that return different classes.
>
> I would like to propose refactoring this so that all three extend
> ClientBaseDataSource directly which will mean moving some of the
> properties from ClientDataSource down into the base class.
>
> Any thoughts on why this should not be done?
>
> --
> Jeremy
>
>
>
Re: DataSource class hierarchy in client
Posted by David Jencks <da...@yahoo.com>.
+ 100
I think implementations such as the one you are proposing to change
have created a great deal of confusion in the java community about the
relationship between DataSource and XADataSource.
If you can make it so ClientBaseDataSource can also be subclassed
easily to implement ManagedConnectionFactory, so much the better.
thanks
david jencks
On May 2, 2005, at 1:38 PM, Jeremy Boynes wrote:
> The class hierarchy the client DataSources is:
>
> ClientBaseDataSource
> |
> +-- ClientDataSource
> |
> +-- ClientXADataSource
> |
> +-- ClientConnectionPoolDataSource
>
> The three standard interfaces DataSource, ConnectionPoolDataSource and
> XADataSource are not related to each other with different
> get??Connection methods that return different classes.
>
> I would like to propose refactoring this so that all three extend
> ClientBaseDataSource directly which will mean moving some of the
> properties from ClientDataSource down into the base class.
>
> Any thoughts on why this should not be done?
>
> --
> Jeremy
>