db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julius Stroffek (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.
Date Tue, 10 Oct 2006 17:12:21 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12441210 ] 
            
Julius Stroffek commented on DERBY-1434:
----------------------------------------

Two machines works fine. It seems that this behaviour does not have any influence on functionality.

The databaseName parameter from the PKGNAMCBytes is never used by the server. The database
is assigned to DRDAConnThread instance only in these functions on the server:

org.apache.derby.impl.drda.DRDAConnThread.parseACCRDB()
org.apache.derby.impl.drda.DRDAConnThread.parseACCSEC()
org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK()

Thus, this behaviour should not cause using a wrong database (unless multiple databases are
used in one session - which is  AFAIK not possible). The PKGNAMCSN is used in OPNQRY (used
by PreparedStatement) to identify a statement in a org.apache.derby.impl.drda.Database.stmTable
(by hashcode). However, the statement was even created with wrong PKGNAMCSN, so the hashes
and even PKGNAMCSN of stored statement match.

I observed a strange behaviour, when I changed the d1434.java (attached as d1434_v2.java)
to insert multiple records in a database. The code in go method looks like (and behaves as
described in comment).

st.execute("create table FIRSTDB_T1 (i int, j int, k int)"); // generates new PKGNAMCSN (but
the same as before)
st.execute("insert into FIRSTDB_T1 values (21, 22, 23)");    // uses already generated PKGNAMCSN
st.execute("insert into FIRSTDB_T1 values (22, 23, 24)");    // generates new PKGNAMCSN (but
the same as before)
st.execute("insert into FIRSTDB_T1 values (23, 24, 25)");    // uses already generated PKGNAMCSN
st.execute("insert into FIRSTDB_T1 values (24, 25, 26)");    // generates new PKGNAMCSN (but
the same as before)

st2.execute("create table SECONDDB_T1 (i int, j int, k int)"); // uses already generated PKGNAMCSN
st2.execute("insert into SECONDDB_T1 values (11, 12, 13)");    // uses already generated PKGNAMCSN
st2.execute("insert into SECONDDB_T1 values (12, 13, 14)");    // uses already generated PKGNAMCSN
st2.execute("insert into SECONDDB_T1 values (13, 14, 15)");    // uses already generated PKGNAMCSN
st2.execute("insert into SECONDDB_T1 values (14, 15, 16)");    // uses already generated PKGNAMCSN


> Client can send incorrect database name to server after having made multiple connections
to different databases.
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1434
>                 URL: http://issues.apache.org/jira/browse/DERBY-1434
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.2.1.6, 10.1.3.1
>            Reporter: A B
>         Assigned To: Julius Stroffek
>             Fix For: 10.2.2.0
>
>         Attachments: _driver_1, d1434.java, d1434_v2.java, Server2.trace
>
>
> I have a simple program that connects to a database using the Derby Client, executes
a simple query, then connects to a different database using a different Connection object
and executes another simple query on that second connection.  The queries both execute without
error, so it appears that the connections are correct--i.e. each query will only work on one
of the databases, and both queries work, therefore each must be getting executed against the
correct database.
> But in looking at the client and server traces, I noticed that for the query on the second
database, the client is actually sending the name of the *first* database as RDBNAM, which
(I think?) is wrong--it should be sending the name of the second database, since the query
is being executed on the second Connection object.
> This behavior does not appear to occur for JCC.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message