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 Fri, 27 Oct 2006 10:21:21 GMT
Hi Bryan,

I'm sorry for missing your comments in creation of a patch - I came back 
to this issue after a couple of days after reading your comments. Thank 
you for reminding.

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.

A small extract from DRDA DDM:
/With SQLAM level 7, the PKGNAMCSN is changed to an optional instance 
variable. If specified,
the values are used as the default package name and consistency token 
for the connection. If not
specified on the command, the PKGSN is required to identify the section 
number. In this case,
the default package name, consistency token, and specified section 
number are used for the
request. If PKGNAMCSN was never specified on the connection, a PRCCNVRM 
is returned.

/According to this specification I think it is possible to change the 
default database name on a connection,
thus theoretically there might exist a request that would require to 
change a database name through
the PKGNAMCSN codepoint. Thus the question is: Will we add a check or 
will we allow a change of
the database name on a connection? It makes no sense to allow a database 
name change for jdbc api...
because AFAIK this stuff is not supported by the jdbc api.

However, I would not recommend allowing a change of the connection just 
now because connecting
with an old implementation of jdbc client to a new implementation of 
server will not work when creating
multiple connections to different databases.

So, I will add these things to the patch:

1.) A check of the database name in PKGNAMCSN codepoint.
2.) A test program doing something similar as the d1434.java attached to 

Would it be alright then?
> And thanks for the detailed analysis of the problem, Julius; it has been
> quite illuminating to read your notes.
Thanks... ;-); I liked going through it...



View raw message