db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendle...@amberpoint.com>
Subject Re: DERBY-1434 - Client can send incorrect database name to server after having made multiple connections to different databases.
Date Sun, 08 Oct 2006 16:47:37 GMT
> 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.



View raw message