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 Sat, 28 Oct 2006 15:16:17 GMT
> So reading your comments again I think the best way how to implement a 
> test is to add a check to DRDAConnThread object and throw an exception
> when the server receives a different RDBNAM in PKGNAMCSN codepoint than 
> the default values of a connection. The test program then could be
> the program specified in JIRA - when the client sends different package 
> name, the exception will be thrown ("RDBNAM Mismatch") and query
> won't be processed. It is sufficient to add this check only to 
> parsePKGNAMCSN function.

This sounds like an excellent solution to me. The server-side check
seems reasonable and appropriate, and the test sounds like it will
be short, sweet, and to the point. Very good!

One thing we should be very careful about, is whether this new server-side
check introduces a compatibility problem.

We don't want the new server to refuse to work with older clients, because
they still have the bug of sending the wrong database name in certain
circumstances. Since we know that using the wrong database name on the
server side is harmless, we should be forgiving with these old clients
and allow them to work without requiring that they be patched for this issue.

So we should code the server-side check such that it only applies to a 10.3
client or above.

I think that with a bit of hunting, you can find some similar version-compat
checks on the server side that we can mimic for this new check.

And then you'll want to run your test program in two configurations:
1) Your new repro test in 10.3 should trip the check, and get the expected failure
2) The original repro program, if built and run using the 10.2 or 10.1 clients,
should quietly not trip your new check, but of course it will run with the wrong
database name so the traces, etc. will be wrong.



View raw message