db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <a...@golux.com>
Subject Regarding DERBY-35...
Date Fri, 08 Oct 2004 21:00:15 GMT

Regarding DERBY-35: DRDA Chaining in Network Server is incorrect

It seems to me like a good fix to this bug should do three things:

1) Make it so that the chaining bit in the DSS reply is set as part of the DDMWriter.endDss()
method, instead of waiting 
until the beginDss() call for the _next_ DSS.

2) Allow setting of the "reuseCorrId" (and thus, indirectly, the setting of the reply chain
bits) in DDMWriter to be 
controlled by the DDMWriter itself, instead of taking the flag as a parameter from DRDAConnThread.
 When the flag is 
passed from DRDAConnThread, there has to be logic surrounding every call to DDMWriter.createDss()
in order to make sure 
that the correct flag is being sent to the writer.  Not only is this ineffecient and prone
to error, but it means that 
any changes to chaining down the road (if there are any) will require re-examination of every
call to 
DDMWriter.createDss(), instead of just requiring changes to DDMWriter.

3) If #1 and #2 can be successfully implemented, then this one probably isn't so important,
but still: it'd be nice if 
we could minimize the calls to "send()" in DRDAConnThread so that they're only used at the
end of the chain.  This 
probably requires more than just adding "if not chained" logic around all the send() calls
that are already there; 
ideally, we could remove most of the send() calls altogether and just have one or two key
calls remaining (for example, 
the call to send() at the end of the DRDAConnThread.processCommands() method would probably
be a keeper).

Note that #1 is not entirely trivial: while it is tempting to say that we could just check
the reader.isChained...() 
methods when we get to DDMWriter.endDss() and set the chaining bits based on that, current
Network Server workings 
wouldn't allow that.  The reason is because the reader.isChained() flags tell us whether or
not the current request is 
chained to the _following_ request, while the "reuseCorrId" flag in DDMWriter has to tell
us whether or not the current 
reply is chained to the _previous_ reply.  It's the clash between the "_following_" and the
"_previous_" that makes #1 
non-trivial.  Take an example:

Assume we're reading three requests, A, B, and C, all of which are chained together.  From
the server side, we have to 
write three replies, AR, BR, and CR.  Since requests are chained, we have to do the following:

a- write AR with some corrId_1
b- write BR with another corrId_2 (which may or may not be equal to corrId_1, depending on
the chain bit)
c- write CR with another corrId_3 (which may or may not be equal to corrId_2, depending on
the chain bit)
d- send

Assume also that we've already written AR, and that we used the reader.isChained...() methods
to figure out that we're 
not supposed to send AR yet.  Then here's what the server would do next:

-= Read the header for request B; now any calls to reader.isChained() will tell us whether
or not B is chained to C.
-= Read, parse, and process request B.
-= Write reply BR.  At the time of "beginDSS", we have to know whether or not BR should have
the same correlation ID as 
AR (i.e. we need to know if 'reuseCorrId' should be true or false).  Once we know that, that
we can go back and update 
the chaining bits for AR.  But how do we know?  We can't check "reader.isChainedWithSameID()"
because that only tells us 
if B is chained to C, not if B was chained to A.

If we can get a fix that accomplishes both #1 and #2 above (and #3 as security), I think we
can avoid this problem.  I 
am currently working to come up with and implement such a fix.

That's my 2-cents, as they say.  (thanks to Kathey Marsden for her input on this).

Any concerns/questions/better ideas?

I am employed by IBM and have been part of the Cloudscape team for just over a year and a
half.  I've spent most of that 
short time doing maintenance/bug fixes for the team (with slight emphasis on Network Server)
and some tool development.

Thanks for taking the time to read this (;)

View raw message