Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4166FFDF.1050608@golux.com>
Date: Fri, 08 Oct 2004 14:00:15 -0700
From: Army <army@golux.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7.1) Gecko/20040707
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Regarding DERBY-35...
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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 (;)
Army