db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@gmail.com>
Subject Re: DERBY-1434 - Client can send incorrect database name to server after having made multiple connections to different databases.
Date Wed, 11 Oct 2006 15:43:02 GMT
Julius Stroffek wrote:
> Query processing is always performed correctly. The only one visible 
> impact is the server trace.

To an end-user that might not mean much, but to developers trying to read a 
trace in order to track down a problem, I think it's important to have correct 
server traces as much as possible.  At the very least, it makes it so that 
people don't stare at the database name in the trace and think, "Hmm...that 
looks wrong...I wonder if that's the cause of the problem I'm 
investigating?"--which is exactly what I spent a half-day doing before I came to 
the conclusion that it wasn't related :)

> The PKGNAMCSN is not a mandatory code point according to DRDA DDM. For 
> now I see these alternatives:
> 1.) Leave the code unchanged. Everything will work fine except the 
> server traces will be confusing.
> 2.) Remove the static modifier from the fields noHoldPKGNAMCBytes and 
> holdPKGNAMCBytes of the org.apache.derby.client.am.SectionManager class.
> 3.) Also remove the static modifier as described above, but also do not 
> send PKGNAMCSN when it is not needed and send PKGSN instead. This needs 
> some more changes to code. The function buildPKGNAMCSN of the 
> NetPackageRequest uses function canCommandUseDefaultPKGNAMCSN() to check 
> whether it should send PKGNAMCSN or PKGSN. However this function always 
> returns false. It seems that its not fully implemented.

If #2 is all it takes to fix the trace, and if there are no negative effects 
(esp. would removing the static fields have a performance impact?  Would it be 
enough to cause concern?), then that's what I vote for.  #1 seems like a shame 
since, as I mentioned above, things as they are can lead to confusion and 
potentially wasted time.  #3 seems like a slight overkill if #2 solves the 
problem and there's no other impact on query processing...


View raw message