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 "Kathey Marsden (JIRA)" <de...@db.apache.org> on 2005/08/20 01:10:54 UTC
[jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection and Networked Connection
[ http://issues.apache.org/jira/browse/DERBY-458?page=comments#action_12319438 ]
Kathey Marsden commented on DERBY-458:
--------------------------------------
Is this a code issue, a documentation issue, or just a question?
> Make it clear the difference between EmbedConnection and Networked Connection
> -----------------------------------------------------------------------------
>
> Key: DERBY-458
> URL: http://issues.apache.org/jira/browse/DERBY-458
> Project: Derby
> Type: Task
> Components: Network Server, Network Client
> Reporter: Tomohito Nakayama
>
> This is question found in DERBY-397.
> There must be significant difference between EmbedConnection and Networked Connection.
> What is the difference between them ?
> It is a significant characteristic of Derby to have EmbedConnection.
> Then, this difference will have special meaning in development of Derby ...
> I think we should discuss in ML ....
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection and Networked Connection
Posted by Satheesh Bandaram <ba...@gmail.com>.
Some of the big differences you see is because of not fully completing
the Derby Client development... like the missing SQLStates or the
message bundle support. These were known issues when Derby client was
released, but I thought it is better to get some working functionality
out there than make it perfect before releasing it.
Kathey also brought up another possible code sharing proposal...
Sharing of protocol managing code between network client and server.
Like she said, it seems we still don't have a good working model for
sharing code that balances compatibility of future and past versions
in a good way yet.
Satheesh
On 8/22/05, David Van Couvering <Da...@sun.com> wrote:
> Hm. Logically I see your point, but I'm not sure I'm convinced. If I
> were to build a new JDBC implementation and I had an existing one in
> place, I would like to inherit as much as possible from the existing
> implementation and diverge only where there is a difference, rather than
> start from scratch, which is basically where things stand now.
>
> In our case, the difference between the two implementation should
> /solely/ be the fact that the interaction with the next layer of Derby -
> I guess that would be the SQL layer - is local or over the network.
> Everything else should be identical (xcept perhaps in cases where you
> would get a very chatty network interaction, and some communication
> efficiencies can be obtained).
>
> Right now we are discovering major differences, and we could pick at
> them one by one, but I do wonder if there is a more efficient way and
> ultimately more maintainable way to accomplish this...
>
> Thanks,
>
> David
>
> Daniel John Debrunner wrote:
>
> >David Van Couvering wrote:
> >
> >
> >
> >>Is it worth considering finding some way for the embedded and client
> >>drivers to share some code, so that the only real difference is that the
> >>network one is sending its commands over the wire?
> >>
> >>
> >
> >Possibly, but then you need common JDBC code that writes to a unified
> >internal api (say derby-db-api), and then there are two implementations
> >of derby-db-api, embedded and network.
> >
> >Thus you have to define a derby-db-api that supports all the
> >functionality of JDBC.
> >
> >The current approach is that derby-db-api is JDBC, and the two
> >implementations are the embedded and client drivers.
> >
> >Maybe an extra level of indirection would save some code, but at the end
> >of the day you still need two implementations of something, one for
> >embedded and one for client.
> >
> >I just don't see this approach would be of much benefit.
> >
> >Dan.
> >
> >
> >
> >
>
>
>
Re: [jira] Commented: (DERBY-458) Make it clear the difference between
EmbedConnection and Networked Connection
Posted by David Van Couvering <Da...@Sun.COM>.
Hm. Logically I see your point, but I'm not sure I'm convinced. If I
were to build a new JDBC implementation and I had an existing one in
place, I would like to inherit as much as possible from the existing
implementation and diverge only where there is a difference, rather than
start from scratch, which is basically where things stand now.
In our case, the difference between the two implementation should
/solely/ be the fact that the interaction with the next layer of Derby -
I guess that would be the SQL layer - is local or over the network.
Everything else should be identical (xcept perhaps in cases where you
would get a very chatty network interaction, and some communication
efficiencies can be obtained).
Right now we are discovering major differences, and we could pick at
them one by one, but I do wonder if there is a more efficient way and
ultimately more maintainable way to accomplish this...
Thanks,
David
Daniel John Debrunner wrote:
>David Van Couvering wrote:
>
>
>
>>Is it worth considering finding some way for the embedded and client
>>drivers to share some code, so that the only real difference is that the
>>network one is sending its commands over the wire?
>>
>>
>
>Possibly, but then you need common JDBC code that writes to a unified
>internal api (say derby-db-api), and then there are two implementations
>of derby-db-api, embedded and network.
>
>Thus you have to define a derby-db-api that supports all the
>functionality of JDBC.
>
>The current approach is that derby-db-api is JDBC, and the two
>implementations are the embedded and client drivers.
>
>Maybe an extra level of indirection would save some code, but at the end
>of the day you still need two implementations of something, one for
>embedded and one for client.
>
>I just don't see this approach would be of much benefit.
>
>Dan.
>
>
>
>
Re: [jira] Commented: (DERBY-458) Make it clear the difference between
EmbedConnection and Networked Connection
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David Van Couvering wrote:
> Is it worth considering finding some way for the embedded and client
> drivers to share some code, so that the only real difference is that the
> network one is sending its commands over the wire?
Possibly, but then you need common JDBC code that writes to a unified
internal api (say derby-db-api), and then there are two implementations
of derby-db-api, embedded and network.
Thus you have to define a derby-db-api that supports all the
functionality of JDBC.
The current approach is that derby-db-api is JDBC, and the two
implementations are the embedded and client drivers.
Maybe an extra level of indirection would save some code, but at the end
of the day you still need two implementations of something, one for
embedded and one for client.
I just don't see this approach would be of much benefit.
Dan.
Re: [jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection and Networked Connection
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I read what Kathey wrote in series of mails as next.
The EmbedConnection and NetworkConnection are different existences at all,
because
EmbedConnection is existence which acts in engine and
NetworkConnection is just an existence of handle to EmbedConnection separeted from engine by network.
//I wonder whether NetworkConnection can be just a handle to EmbedConnection, however I'm just wondering it.
On the other hand, server side object and client side object , which compose NetworkConnection ,
seems to have similarity.
e.g. Request.java and DDMWriter.java, Reply.java and DDMReader.java .
These code might be shared.
>Can you close out DERBY-458 and file the code or doc issue if it arises.
I see ... I will log contents of these mails (especially references which needs to understand network implementation of derby (
Thank you :) ) in JIRA and close it.
Please give me time to put my brain in order.
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Kathey Marsden" <km...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Tuesday, August 23, 2005 9:01 AM
Subject: Re: [jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection and Networked Connection
> David Van Couvering wrote:
>
>> Is it worth considering finding some way for the embedded and client
>> drivers to share some code, so that the only real difference is that
>> the network one is sending its commands over the wire? This again
>> broaches the topic of veering away from DRDA...
>>
>>>
> Well hopefully the client gets thinner and thinner and the Derby
> embedded behavior gets exposed more. Ideally we are just looking for
> a remote execution and share code that way. I found this with my fix
> for DERBY-250. Rip out a bunch of code, fix a few bugs and increase
> client/embedded compat.
> Protocol limitations make this hard sometimes but in those cases I don't
> think a common JDBC implementation api is going to help, although some
> of the code certainly might as you have found with your localization
> project.
>
>
> Where I think there are great opportunities for code sharing is in the
> handling of the protocol, especially the core duplications in client
> and server. You will see great similarities in Request.java and
> DDMWriter.java, Reply.java and DDMReader.java. and the parsing and
> writing of DDM Objects could be generalized for both. This is an area
> where I think we could most realistically have a well defined internal
> API, since conventions could be set and adding support for a new
> codepoint or datatype wouldn't cause any problems with jar mixing.
> The big thing is that I don't know how we would enforce backward
> compatibility in an open source environment. Some of the methods are
> tested explicitly in the protocol tests, but I could easily see a patch
> that just removed those tests slip through the cracks or new tests not
> getting added for new methods. I am still hoping a less risky means for
> code sharing presents itself.
>
>
> Kathey
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.338 / Virus Database: 267.10.14/79 - Release Date: 2005/08/22
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.14/79 - Release Date: 2005/08/22
Re: [jira] Commented: (DERBY-458) Make it clear the difference between
EmbedConnection and Networked Connection
Posted by Kathey Marsden <km...@sbcglobal.net>.
David Van Couvering wrote:
> Is it worth considering finding some way for the embedded and client
> drivers to share some code, so that the only real difference is that
> the network one is sending its commands over the wire? This again
> broaches the topic of veering away from DRDA...
>
>>
Well hopefully the client gets thinner and thinner and the Derby
embedded behavior gets exposed more. Ideally we are just looking for
a remote execution and share code that way. I found this with my fix
for DERBY-250. Rip out a bunch of code, fix a few bugs and increase
client/embedded compat.
Protocol limitations make this hard sometimes but in those cases I don't
think a common JDBC implementation api is going to help, although some
of the code certainly might as you have found with your localization
project.
Where I think there are great opportunities for code sharing is in the
handling of the protocol, especially the core duplications in client
and server. You will see great similarities in Request.java and
DDMWriter.java, Reply.java and DDMReader.java. and the parsing and
writing of DDM Objects could be generalized for both. This is an area
where I think we could most realistically have a well defined internal
API, since conventions could be set and adding support for a new
codepoint or datatype wouldn't cause any problems with jar mixing.
The big thing is that I don't know how we would enforce backward
compatibility in an open source environment. Some of the methods are
tested explicitly in the protocol tests, but I could easily see a patch
that just removed those tests slip through the cracks or new tests not
getting added for new methods. I am still hoping a less risky means for
code sharing presents itself.
Kathey
Re: [jira] Commented: (DERBY-458) Make it clear the difference between
EmbedConnection and Networked Connection
Posted by David Van Couvering <Da...@Sun.COM>.
Is it worth considering finding some way for the embedded and client
drivers to share some code, so that the only real difference is that the
network one is sending its commands over the wire? This again broaches
the topic of veering away from DRDA...
David
Kathey Marsden wrote:
>TomohitoNakayama wrote:
>
>
>
>>Hello.
>>
>>I think this is a question , which may raise up document and code issue.
>>//Reading spec of DRDA at opengroup (http://www.opengroup.org/) is
>>best shortcut ?
>>
>>
>
>I've never heard that specification described as a shortcut #:), but
>yes that is the protocol that is used.
>As for your question about the difference between EmbedConnection and
>Networked Connection ...
>
>The Networked Connection is really just a remote handle to an
>EmbedConnection. The network client JDBC driver translates JDBC calls
>into protocol sent over TCP/IP and then Network Server translates that
>protocol back into JDBC calls to the Embedded driver. The whole system
>is a JDBC -> protocol -> JDBC converter. So for every client
>connection there is a corresponding EmbedConnection doing the real
>work. Sometimes the JDBC on the server side is not exactly the client
>JDBC call but some equivalent, for example,
>DriverManager.getConnection() will become Driver.connect() within
>network server. Sometimes also network server uses Derby internal
>intefaces where a straight JDBC call is not available, but generally try
>to avoid it.
>
>Some places to do more reading.
>
>Some general info on network server in the user guide at
>http://db.apache.org/derby/docs/10.1/adminguide/cadminov825266.html
>
>The client functional spec
>http://db.apache.org/derby/papers/DerbyClientSpec.html
>
>The protocol specs
>http://www.opengroup.org/dbiop
>In Volume 1 take a look at Figure 4-2 Establishing a Connection to a
>Remote Database Manager
>This shows the protocol flow for creating a connection. You can find
>definitions of specific DDM objects referenced there, e.g. ACCRDB, in
>the DDM manual (Volume 3).
>
>I think the figures in Chapter 4 of volume 1 are a good place to get a
>general idea of the protocol flow without having to do a lot of
>translation. Sorry, don't know of anyone who has tried to translate
>this spec into Japanese #:)
>
>I hope I understood the question correctly.
>Can you close out DERBY-458 and file the code or doc issue if it arises.
>
>Thanks
>
>Kathey
>
>
>
Re: [jira] Commented: (DERBY-458) Make it clear the difference between
EmbedConnection and Networked Connection
Posted by Kathey Marsden <km...@sbcglobal.net>.
TomohitoNakayama wrote:
> Hello.
>
> I think this is a question , which may raise up document and code issue.
> //Reading spec of DRDA at opengroup (http://www.opengroup.org/) is
> best shortcut ?
I've never heard that specification described as a shortcut #:), but
yes that is the protocol that is used.
As for your question about the difference between EmbedConnection and
Networked Connection ...
The Networked Connection is really just a remote handle to an
EmbedConnection. The network client JDBC driver translates JDBC calls
into protocol sent over TCP/IP and then Network Server translates that
protocol back into JDBC calls to the Embedded driver. The whole system
is a JDBC -> protocol -> JDBC converter. So for every client
connection there is a corresponding EmbedConnection doing the real
work. Sometimes the JDBC on the server side is not exactly the client
JDBC call but some equivalent, for example,
DriverManager.getConnection() will become Driver.connect() within
network server. Sometimes also network server uses Derby internal
intefaces where a straight JDBC call is not available, but generally try
to avoid it.
Some places to do more reading.
Some general info on network server in the user guide at
http://db.apache.org/derby/docs/10.1/adminguide/cadminov825266.html
The client functional spec
http://db.apache.org/derby/papers/DerbyClientSpec.html
The protocol specs
http://www.opengroup.org/dbiop
In Volume 1 take a look at Figure 4-2 Establishing a Connection to a
Remote Database Manager
This shows the protocol flow for creating a connection. You can find
definitions of specific DDM objects referenced there, e.g. ACCRDB, in
the DDM manual (Volume 3).
I think the figures in Chapter 4 of volume 1 are a good place to get a
general idea of the protocol flow without having to do a lot of
translation. Sorry, don't know of anyone who has tried to translate
this spec into Japanese #:)
I hope I understood the question correctly.
Can you close out DERBY-458 and file the code or doc issue if it arises.
Thanks
Kathey
Re: [jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection and Networked Connection
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I think this is a question , which may raise up document and code issue.
//Reading spec of DRDA at opengroup (http://www.opengroup.org/) is best shortcut ?
Best regards.
/*
Tomohito Nakayama
tomonaka@basil.ocn.ne.jp
tomohito@rose.zero.ad.jp
tmnk@apache.org
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Kathey Marsden (JIRA)" <de...@db.apache.org>
To: <de...@db.apache.org>
Sent: Saturday, August 20, 2005 8:10 AM
Subject: [jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection and Networked Connection
> [ http://issues.apache.org/jira/browse/DERBY-458?page=comments#action_12319438 ]
>
> Kathey Marsden commented on DERBY-458:
> --------------------------------------
>
> Is this a code issue, a documentation issue, or just a question?
>
>
>
>
>
>> Make it clear the difference between EmbedConnection and Networked Connection
>> -----------------------------------------------------------------------------
>>
>> Key: DERBY-458
>> URL: http://issues.apache.org/jira/browse/DERBY-458
>> Project: Derby
>> Type: Task
>> Components: Network Server, Network Client
>> Reporter: Tomohito Nakayama
>
>>
>> This is question found in DERBY-397.
>> There must be significant difference between EmbedConnection and Networked Connection.
>> What is the difference between them ?
>> It is a significant characteristic of Derby to have EmbedConnection.
>> Then, this difference will have special meaning in development of Derby ...
>> I think we should discuss in ML ....
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 2005/08/18
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 2005/08/18