db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Stroffek <Julius.Strof...@Sun.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:21:57 GMT
Hi Bryan,

Thank You for your answers. I spent more time on this (see updates in JIRA)

Bryan Pendleton wrote:
> 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.
Exactly, PKGNAMCSN is used only for hashing of statements on server side.
The section number in PKGNAMCSN code point is specified correctly 
(that's why using multiple prepared statements on the same connection 
works fine).
> 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.
Query processing is always performed correctly. The only one visible 
impact is the server trace.
> 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.
This is probably not possible.

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.

What do you think?



View raw message