[
http://issues.apache.org/jira/browse/DERBY-864?page=comments#action_12363878 ]
Knut Anders Hatlen commented on DERBY-864:
------------------------------------------
David's question: Do we have version detection at that level of granularity in
the protocol?
The client driver has a class ProductLevel with methods
- boolean greaterThanOrEqualTo(int versionLevel, int releaseLevel, int
modificationLevel)
- boolean lessThan(int versionLevel, int releaseLevel, int modificationLevel)
which let you detect the version of the server.
In Reply.java, we could have something like this:
if
(netAgent_.netConnection_.databaseMetaData_.productLevel_.greaterThanOrEqualTo(10,
2, 0)) {
// new behaviour
} else {
// old behaviour
}
> Network Client should not assume length of Layer B segment is 32K
> -----------------------------------------------------------------
>
> Key: DERBY-864
> URL: http://issues.apache.org/jira/browse/DERBY-864
> Project: Derby
> Type: Improvement
> Components: Network Client
> Versions: 10.2.0.0
> Reporter: Bryan Pendleton
> Priority: Minor
>
> The Network Client, when processing a Layer-B Segmented DSS block, currently
> uses the following code:
> [java/client/org/apache/derby/client/net/Reply.java]:
> if ((continueHeaderLength & 0x8000) == 0x8000) {
> // the last dss header is again continued
> continueHeaderLength = 32767;
> dssIsContinued_ = true;
> } else {
> // the last dss header was not contiued so update
> continue state flag
> dssIsContinued_ = false;
> }
> According to my reading of the DRDA spec, this code is making an assumption
> which is not truly justified by the DSS protocol, namely that if a segment is
> continued, then its length must be 32767. In practice, the Network Server
> does implement such a behavior, but I think it would be safer for the client
> to not make such an assumption, and rather it should get the *actual* length
> from the contents of the DSS continuation header.
> However, there is a slight complexity here. Prior to the fix for DERBY-125,
> the Network Server did not set the length value of the DSS Continuation
> Header. Instead of sending a DSS Continuation Header of 0xFFFF, it sent a
> value of 0x8000.
> Therefore, when changing the client, care must be taken to not break
> compatibility between a new client and an old server. I can think of two ways
> to do this:
> - if the client sees that the the length is 0, it could treat a length of 0
> as meaning a length of 32767, or
> - if the client can detect the version of the server, and can see that the
> server is a version prior to DERBY-125, it could assume that the length is
> always 32767, as it does now.
> See http://wiki.apache.org/db-derby/DssProtocolErrors for more information on
> DSS continuations, and see DERBY-125 for some other background information
> on this issue.
--
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
