[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-12-08 Thread Julius Stroffek (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12456741 ] 

Julius Stroffek commented on DERBY-1434:


Could we just remove the static modifier from the fields noHoldPKGNAMCBytes and 
holdPKGNAMCBytes of the org.apache.derby.client.am.SectionManager class in 10.2 
branch and update the version check in trunk? So porting no tests for 10.2 
branch.

> 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.3.0.0
>
> Attachments: _driver_1, d1434.java, d1434_v2.java, 
> derby-1434-trunk-diff.txt, derby1434-try2.diff, derby1434-try2.diff, 
> derby1434-try2.stat, derby1434-try3.diff, 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-12-06 Thread Knut Anders Hatlen (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12455931 ] 

Knut Anders Hatlen commented on DERBY-1434:
---

This fix cannot be merged to 10.2 automatically because it depends on some 
changes to the JUnit framework that have not been back-ported. It also contains 
a version check which should be changed if we port the fix (this check should 
also be changed on trunk if we back-port the fix).

> 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.3.0.0
>
> Attachments: _driver_1, d1434.java, d1434_v2.java, 
> derby-1434-trunk-diff.txt, derby1434-try2.diff, derby1434-try2.diff, 
> derby1434-try2.stat, derby1434-try3.diff, 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-12-05 Thread Rajesh Kartha (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12455757 ] 

Rajesh Kartha commented on DERBY-1434:
--

I think this will be a useful fix for the 10.2 branch also, can one of the 
committers look into porting the fix.

> 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.3.0.0
>
> Attachments: _driver_1, d1434.java, d1434_v2.java, 
> derby-1434-trunk-diff.txt, derby1434-try2.diff, derby1434-try2.diff, 
> derby1434-try2.stat, derby1434-try3.diff, 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-11-24 Thread Julius Stroffek (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12452406 ] 

Julius Stroffek commented on DERBY-1434:


The last sentense in the description of the issue states that the JCC driver 
works fine, so I have not tested this before.

I tried to run the test program manually for DB2JCC and it works fine.

> 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.3.0.0
>
> Attachments: _driver_1, d1434.java, d1434_v2.java, 
> derby-1434-trunk-diff.txt, derby1434-try2.diff, derby1434-try2.diff, 
> derby1434-try2.stat, derby1434-try3.diff, 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-11-23 Thread Knut Anders Hatlen (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12452247 ] 

Knut Anders Hatlen commented on DERBY-1434:
---

Thanks for the explanations, Julo. They all make sense. So DRDAConnThread is 
supposed to check that the database name is correct if the DB2 client is used 
as well? Have you tested that it works with the DB2 client?

> 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.3.0.0
>
> Attachments: _driver_1, d1434.java, d1434_v2.java, 
> derby-1434-trunk-diff.txt, derby1434-try2.diff, derby1434-try2.diff, 
> derby1434-try2.stat, derby1434-try3.diff, 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-11-22 Thread Knut Anders Hatlen (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12452082 ] 

Knut Anders Hatlen commented on DERBY-1434:
---

Hi Julo,

I haven't followed the discussion about this bug closely enough to say
whether the fix is correct, but it looks like it follows the approach
which was suggested in the discussion. The changes to the protocol
test also seem to be correct.

A couple of questions/comments:

 - DRDAConnThread checks the version of the client. Is the check
   correct? Shouldn't the condition be
 (appRequester.getClientType() == AppRequester.DNC_CLIENT
   && appRequester.greaterThanOrEqualTo(10,3,0)) ?

 - The class name in the copyright header in DRDAProtocolTest is wrong
   ("lang" should be "derbynet").

 - I think it would be good if the test case in DRDAProtocolTest had a
   comment which described what it is testing. Is it supposed to fail
   without the fix? In my environment it runs successfully even when
   the fix is not applied.

 - It seems like your editor is set up with tab stops at eight
   characters. The Derby code uses tab stops at four characters, so
   the indentation does not match the indentation of the surrounding
   code. It would be good if you changed your tab settings and fixed
   the indentation.

Thanks.

> 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.3.0.0
>
> Attachments: _driver_1, d1434.java, d1434_v2.java, 
> derby-1434-trunk-diff.txt, derby1434-try2.diff, derby1434-try2.diff, 
> derby1434-try2.stat, 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-11-15 Thread Julius Stroffek (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12450102 ] 

Julius Stroffek commented on DERBY-1434:


Just want to add that I ran all the junit tests and derbyall harness suit.

> 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.3.0.0
>
> Attachments: _driver_1, d1434.java, d1434_v2.java, 
> derby-1434-trunk-diff.txt, derby1434-try2.diff, derby1434-try2.diff, 
> derby1434-try2.stat, 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-11-15 Thread Julius Stroffek (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12450097 ] 

Julius Stroffek commented on DERBY-1434:


Sorry for a mess in uploaded files, my connection got broken during first 
upload.

These file describes my change:

derby1434-try2.diff (attached multiple times, should have the same content)
derby1434-try2.stat



> 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.3.0.0
>
> Attachments: _driver_1, d1434.java, d1434_v2.java, 
> derby-1434-trunk-diff.txt, derby1434-try2.diff, derby1434-try2.diff, 
> derby1434-try2.stat, 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-10-11 Thread Julius Stroffek (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12441470 ] 

Julius Stroffek commented on DERBY-1434:


The database is also choosed from RDBNAM code point also in these terms: 
OPNQRY, CNTQRY, PRPSQLSTT, DSCSQLSTT, EXCSQLSTT, EXCSQLIMM, EXCSQLSET, CLSQRY

However, it have to be present in terms ACCRDB, ACCSEC or SECCHK in the 
connection before. If it is not, the error "RDBNAM Mismatch" is produced.

> 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-10-11 Thread Julius Stroffek (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12441455 ] 

Julius Stroffek commented on DERBY-1434:


Sumarization of behaviour:

1.) For each connection to a database a Session object is created on a server. 
It is processed by a separate DRDAConnThread instance thread.

2.) The database is assigned to DRDAConnThread object from the RDBNAM codepoint 
from terms ACCRDB, ACCSEC or SECCHK, which works correctly.

3.) The Section Number in PKGNAMCSN code point is sent always correctly. This 
causes no problem with processing terms like CNTQRY or CLSQRY. The 
corresponding DRDAStatement object is found by looking for the whole PKGNAMCSN 
content. Because the wrong PKGNAMCSN is sent all the time and processed by the 
same instance of DRDAConnThread - it works also fine. The corresponding 
statements are managed locally by DRDAConnThread instance and the right 
statement is identified by the section number which is sent correctly.

3.) In case of these terms PRPSQLSTT, EXCSQLIMM, OPNQRY, CNTQRY, CLSQRY, 
PRPSQLSTT, DSCSQLSTT, EXCSQLSTT, the codepoint PKGNAMCSN is optional in DRDA 
DDM but is mandatory for Derby's implementation. Instead of sending PKGNAMCSN 
the PKGSN code point is sufficient. This might increase a performance a bit. 
Derby has also some optimalizations parsing the pkgnamcsn assuming that 
PKGNAMCSN is the same most of the time (I cannot see any case when it should 
differ).

Small note:
Code point PKGNAMCSN is optional in EXCSQLSET (even not described by DRDA DDM, 
but sent only by jcc1.2 driver), but according the comments in parseEXCSQLSET 
it is also required (changing the comment is sufficient).

> 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-10-10 Thread Julius Stroffek (JIRA)
[ 
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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-10-10 Thread Julius Stroffek (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12441150 ] 

Julius Stroffek commented on DERBY-1434:


Just posting the message below to the right place:
---

When client creates multiple connections to different databases (through the 
JDBC driver), the DRDA protocol 'always' (I'm not sure if always but i have not 
found any situation when it does not) sends the same PKGNAMCSN block as the one 
used for a first created connection.

The reason of this behaviour is in a creation of the Section object in 
SectionManager using it's method 'getDynamicSection'. It creates the section by 
calling the

getSection(freeSections[Non]Hold_, packageNameWith[No]Hold__, 
cursorNamePrefixWith[No]Hold__, resultSetHoldability)

which later calls the init method of the Section class with the parameter 
isGenerated = false. Due to this the buffer which is used to store the 
PKGNAMCSN is initialized to the value stored in 
Agent.SectionManager.holdPKGNAMCBytes - this field is declared static so the 
value is shared among all created connections. The reusing of the value from 
the buffer is probably only a performance improvement and if the value in a 
Section object (created with isGenerated = false) is not initialized it is 
generated on demand and also stored to SectionManager.holdPKGNAMCBytes.

I would suggest removing the static modifier from the fields noHoldPKGNAMCBytes 
and holdPKGNAMCBytes of the org.apache.derby.client.am.SectionManager class. 
Each Connection objects holds its own Agent object which holds its own 
SectionManager object. Thus, the PKGNAMCSN blocks will be generated once for 
each Connection object. Is this right?

However, the description of DRDA protocol looks like a PKGNAMCSN block is 
important to identify the correct server's sql executional package (I'm not an 
expert, it's only my opinion). How it is possible that sending a wrong 
PKGNAMCSN does not affect the database behavior? In the demonstration program 
on JIRA both connections connect to the same server instance. Might connecting 
these connections to different machines (or only server instances) lead to 
improper behavior? Why requests with the wrong PKGNAMCSN still work? I'll try 
two different machines tomorrow (approx. in 16 hours) and let you know.


> 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, 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




[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-06-22 Thread Kathey Marsden (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417392 ] 

Kathey Marsden commented on DERBY-1434:
---

Wish I could delete the comment but the early closed result set with is issue 
is not a valid symptom.  This wrong line caused the test to fail.  Should have 
been ps2.

ResultSet rs2 = ps.executeQuery(); 

> 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
> Type: Bug

>   Components: Network Client
> Versions: 10.2.0.0, 10.1.3.0, 10.1.2.5
> Reporter: A B
>  Fix For: 10.2.0.0
>  Attachments: Server2.trace, _driver_1, d1434.java
>
> 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



[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-06-22 Thread Kathey Marsden (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417352 ] 

Kathey Marsden commented on DERBY-1434:
---

Well, I guess I have a little to say about the client code.
It looks like our client SectionManager logic is fatally flawed when it comes 
to two databases. It has these two static variables  for hold and non-hold  
package names and consistency tokens.  

// noHoldPKGNAMCBytes stores PKGNAMCBytes when holdability is no hold
public static byte[] holdPKGNAMCBytes = null;
public static byte[] noHoldPKGNAMCBytes = null;

There seems to be a databaseName parameter for each SectionManager, so I don't 
understand why these  are static.


> 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
> Type: Bug

>   Components: Network Client
> Versions: 10.2.0.0, 10.1.3.0, 10.1.2.5
> Reporter: A B
>  Fix For: 10.2.0.0
>  Attachments: Server2.trace, _driver_1, d1434.java
>
> 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



Re: [jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-06-21 Thread Kathey Marsden

Kathey Marsden (JIRA) wrote:

   [ http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417238 ] 


Kathey Marsden commented on DERBY-1434:
---

A USER SYMPTOM

I see that if our table in the first database has more data than can be 
retrieved in one QRYDTA  this can cause a  ResultSet to close prematurely if a 
query is executed against the second database before  all results are fetched 
from the server.

 



Also I failed to mention that  actual problem in the user case  I am  
looking at is a  Disconnect exception.  I don't see how this could 
relate really, but thought I would mention it since this issue arose out 
of  looking at their trace files and we don't have a reproduction yet 
for their Disconnect Exception.


If anyone can think of a way this could cause a DisconnectException, 
speak up.


IP  org.apache.derby.client.am.DisconnectException: A communication 
error has been detected. Communication protocol being used: 
Reply.fill(). Communication API being used: InputStream.read(). Location 
where the error was detected: insufficient data. Communication function 
detecting the error: *. Protocol specific error codes(s) TCP/IP 
SOCKETSat 
org.apache.derby.client.net.NetAgent.throwCommunicationsFailure(Unknown 
Source)

   at org.apache.derby.client.net.Reply.fill(Unknown Source)
   at 
org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Unknown Source)

   at org.apache.derby.client.net.Reply.readDssHeader(Unknown Source)
   at 
org.apache.derby.client.net.Reply.startSameIdChainParse(Unknown Source)
   at 
org.apache.derby.client.net.NetResultSetReply.readFetch(Unknown Source)
   at org.apache.derby.client.net.ResultSetReply.readFetch(Unknown 
Source)
   at org.apache.derby.client.net.NetResultSet.readFetch_(Unknown 
Source)

   at org.apache.derby.client.am.ResultSet.flowFetch(Unknown Source)
   at org.apache.derby.client.net.NetCursor.getMoreData_(Unknown 
Source)

   at org.apache.derby.client.am.Cursor.next(Unknown Source)
   at org.apache.derby.client.am.ResultSet.nextX(Unknown Source)
   at org.apache.derby.client.am.ResultSet.next(Unknown Source)
  








[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-06-21 Thread Kathey Marsden (JIRA)
[ 
http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12417238 ] 

Kathey Marsden commented on DERBY-1434:
---

A USER SYMPTOM

I see that if our table in the first database has more data than can be 
retrieved in one QRYDTA  this can cause a  ResultSet to close prematurely if a 
query is executed against the second database before  all results are fetched 
from the server.

TRIGGERING SCENARIO

I am working with a user database, and  don't have the case incorporated into 
Army's repro , but  below is the general  code flow.

 PreparedStatement ps = conn1.prepareStatement(sql);

  rs = ps.executeQuery();  // execute a query from db 1 that returns a 
lot of  data
  // get some data
  rs.next();
  // now interject another statement.
  // This will reuse the statement id (pkgnamcsn) from our old db and 
close it.
  PreparedStatement ps2 = conn2.prepareStatement("Select count(*) from 
sys.systables");
  ResultSet rs2 = ps.executeQuery();
  rs2.next();
  // now lets try to get the rest of the data from our first query.
int rownum = 1;
while(rs.next()){
   
}


THE EXCEPTION

SQLException: org.apache.derby.client.am.SqlException: Invalid operation: 
result set closed
org.apache.derby.client.am.SqlException: Invalid operation: result set closed
at 
org.apache.derby.client.am.ResultSet.checkForClosedResultSet(ResultSet.java:3287)
at org.apache.derby.client.am.ResultSet.nextX(ResultSet.java:250)
at org.apache.derby.client.am.ResultSet.next(ResultSet.java:240)


This occurs because  Network Server keys statements off of the PKGNAMCSCN which 
will be duplicated by the client incorrectly  in this case.  
The relevant server side code is in: org.apache.derby.impl.drda.Database:
protected DRDAStatement newDRDAStatement(Pkgnamcsn pkgnamcsn)
throws SQLException
{
DRDAStatement stmt = getDRDAStatement(pkgnamcsn);
if (stmt != null) {
stmt.close();
stmt.reset();
}
It closes the statement as soon as it gets the duplicate pkgnamcsn in.   Of 
course the problem is that the client code sends a dup, not that the server 
closes when it sees a dup, but I don't  know where that code is off the top of 
my head #:)





> 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
> Type: Bug

>   Components: Network Client
> Versions: 10.1.2.5, 10.1.3.0, 10.2.0.0
> Reporter: A B
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: Server2.trace, _driver_1, d1434.java
>
> 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