db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3198) Using setQueryTimeout will leak sections
Date Tue, 27 Nov 2007 20:32:43 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dyre Tjeldvoll updated DERBY-3198:
----------------------------------

    Derby Info:   (was: [Patch Available])

Hi Knut,
Thanks for taking the time to look at the patch. I'll try to answer your questions:

Q: Will there ever be a case when section_ is null so that we need to generate a new one?
A: Yes, if you don't check for null, you'll get an NPE.

Q: And if we generate a new one, will that one be reused later?
A: That depends on where setSpecialRegister is called. Sometimes it will be reused, but other
times a new Section will be allocated regardless.

Q: or will a new one be allocated and section_ replaced without
freeing the old one?  
A: No, I actually don't think that will
happen. As far as I can tell, the only place where section_ is
assigned without verifying that it is null or that the 
previous value has been freed, is in Statement's constructor and init methods.

Q: 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?  
A: Possibly. But my impression is that the Section stored in the
section_ variable is reused only when you don't care about the
type of Section. In the case where the holdability of the Section
actually matters, a separate Section, with the proper
holdability, is kept in a local variable (newSection), and this
variable is transfered to the section_ variable after its
previous value is freed. I could be wrong about this, though.


I like your idea about using a separate member variable for
tracking the Section used in setSpecialRegister and I agree that
it more closely mimics the old behavior. The only reason for not
choosing that option from the beginning was that I did not see
any other method that did its own Section management like that. 


> 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.


Mime
View raw message