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 14:31:20 GMT
    [ 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__,

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:,
>            Reporter: A B
>         Assigned To: Julius Stroffek
>             Fix For:
>         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


View raw message