[
https://issues.apache.org/jira/browse/DERBY-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549027
]
Dyre Tjeldvoll commented on DERBY-3198:
---------------------------------------
>From what I can tell, the call to Section.free() in
>Statement.initResetStatement() can either come from a call to Statement's
>constructor, or from a chain of 13(!) method calls originating from
>ClientPooledConnection.reset().
My interpretation of this is that by freeing Sections in initResetStatement()
we ensure that Statements belonging to unused Connections in a connection pool
do not hold on to Section objects. This sounds reasonable, so I think it is a
good idea to free setSpecialRegisterSection_ in Statement.initResetStatement()
as well.
> 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
> Assignee: Dyre Tjeldvoll
> Attachments: derby-3198.v1.diff, derby-3198.v2.diff,
> derby-3198.v3.diff, derby-3198.v4.diff, derby-3198.v5.diff, 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.
