[
https://issues.apache.org/jira/browse/DERBY-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545874
]
Knut Anders Hatlen commented on DERBY-3198:
-------------------------------------------
Hi Dyre,
Your patch is probably OK, but there are two things that are not quite clear to
me:
1) Will there ever be a case when section_ is null so that we need to generate
a new one? And if we generate a new one, will that one be reused later, or will
a new one be allocated and section_ replaced without freeing the old one?
2) When a section is created on the fly, its holdability is set to
HOLD_CURSORS_OVER_COMMIT. Should we instead have used the holdability of the
statement, since this section can now be used for other statements than the set
special register statement?
If Statement instead had a field called specialRegisterSection which, if not
null, was freed at the same time as section_ was freed, I think it would be
easier to understand the fix, and the behaviour would be closer to the old one
(with the exception of the leak, of course :)
> 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, 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.
