[ 
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

        

Reply via email to