Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <452D1D39.8000600@amberpoint.com>
Date: Wed, 11 Oct 2006 09:35:05 -0700
From: Bryan Pendleton <bpendleton@amberpoint.com>
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: DERBY-1434 - Client can send incorrect database name to server
 after having made multiple connections to different databases.
References: <452521B4.7080209@sun.com> <45292BA9.2070700@amberpoint.com>
 <452D0C15.8050706@sun.com> <452D1106.60109@gmail.com>
In-Reply-To: <452D1106.60109@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> If #2 is all it takes to fix the trace, and if there are no negative 
> effects, then that's what I vote for. 

I agree. Fixing the trace is important, sending the right database name
in the PKGNAMCSN is important, and solution #2 gets my vote as well.

I think it was important to explore the issue to this level of detail,
to satisfy ourselves that there were no other functional problems besides
the trace (that is, that we didn't execute the wrong queries, or mix up
the results from two queries issued at the same time, or something like that).

Also, I was hoping that we would be able to construct a regression test
for this change, as something other than:
  - run this test program with these trace flags set
  - read the trace files and make sure they look ok
as I would have preferred to see a more automatic regression test of some sort.

But I haven't thought of a simple way to write such a regression test.

Julius, I think that it's still worth incorporating your test program(s) into
the patch as you construct it, even though using those test programs requires
some manual actions (enabling the trace flags, reading the trace files). I think
it would be good to include the instructions for how to use the test program(s)
to verify the correct operation of the patch as code comments in the test programs
themselves. This will be useful at least during the review of the patch, but
I think that there's no harm in including the test programs as a permanent part
of the regression suite, as they exercise a certain path through the code and
shouldn't cause too much of a performance impact.

And thanks for the detailed analysis of the problem, Julius; it has been
quite illuminating to read your notes.

thanks,

bryan