[
https://issues.apache.org/jira/browse/DERBY-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544883
]
Dyre Tjeldvoll commented on DERBY-3198:
---------------------------------------
Based on what I see methods similar to writeSetSpecialRegister do, I think a
safe and reasonable way of getting a Section is as follows:
1) If the surrounding code has set the newSection variable, use that. This will
usually be the case when writeSetSpecialRegister is used to request session
data, as it happens after this variable has been assigned.
2) If Statement.section_ is not null, it is probably safe to use it.
3) if Statement.section_ is null, request a new one from the SectionManager and
assign that to section_. Assigning it to section_ will ensure that it is freed
later.
Doing so does, however, require a change to the signature of the
writeSetSpecialRegister() methods in the Net-layer, so that the Section to use
can be passed in as a parameter (this seems to be how it is done in other write
methods). The change is necessary because the decision about which Section to
use need to happen in the am-layer. It cannot be done in NetStatementRequest
as it currently is, because there we don't have access to the Section variables
mentioned earlier.
I'm wondering if the ability to access the SectionManager from the Net-layer is
an unintended loophole. Seems like NetStatementReply.writeSetSpecialRegister()
is the only place in the net package where it is used. The SectionManager is
accessed through a public member in am.Agent which has the following comment:
public SectionManager sectionManager_ = null; // temporarily public, make
friendly at least !!
The Net-layer gets at this member because NetAgent extends am.Agent.
> Using setQueryTimeout will leak sections
> -----------------------------------------
>
> Key: DERBY-3198
> URL: https://issues.apache.org/jira/browse/DERBY-3198
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.3.1.4
> Reporter: Dyre Tjeldvoll
> Attachments: repro.diff
>
>
> The implementation of setQueryTimeout relies on
> NetStatementReply.writeSetSpecialRegister() which will allocate a dynamic
> section when called. No reference to this Section object is kept, and so
> Section.free() never gets called on it. Executing the same statment
> repeatedly with a query timeout set results in the client driver throwing an
> exception because the number of Sections exceeding 32000.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
