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...
Army
