I spend some time analyzing the communication protocol to find out something related to solution of DERBY-1434.
Thanks for looking at this problem!
I would suggest removing the static modifier from the fields noHoldPKGNAMCBytes and holdPKGNAMCBytes
I think that is a good direction to pursue. I see from the comments in Jira that Kathey was thinking along the same lines.
How it is possible that sending a wrong PKGNAMCSN does not affect the database behavior?
I think this is a key question, and we should figure it out before we have a complete change. My hunch is that the reason this doesn't cause many symptoms is because the PKGNAMCSN is basically used as a hash key on the server side, and so it doesn't really care about the contents too much; it is just using those tokens as unique identifiers to distinguish the various different statements that the client and server are currently working with. If you look at the handling of OPNQRY on the server side (see parseOPNQRY in DRDAConnThread.java), you'll find that the server is getting the database name from the RDBNAM field, not from the PKGNAMCSN field, so that may be a clue to why the server doesn't experience any problems with the database name being incorrect in the PKGNAMCSN field. CNTQRY is handled similarly; it passes a separate RDBNAM codepoint. Do you have a test program which demonstrates a concrete, user-visible symptom of this problem? The repro program attached to the bug causes Derby to write some strange looking trace files, but the actual query processing is all performed correctly. There is a second repro program in the bug comments, but I think we've decided that that program had a bug in it, and does not demonstrate a bug in Derby itself. So it would be really good if you could construct a test program which demonstrates the symptoms of the incorrect PKGNAMCSN field more vividly: incorrect query execution, crash or error message on the server side, etc. I think this will make it easier to evaluate the impact of the change that you propose to the client-side SectionManager. thanks, bryan
