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

["Julius Stroffek (JIRA)" <de...@db.apache.org>]

    [ 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