[
https://issues.apache.org/jira/browse/CALCITE-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964978#comment-15964978
]
Julian Hyde commented on CALCITE-1739:
--------------------------------------
No. If we removed those lines the underlying statement and connection would be
closed before the caller has chance to read the rows from the
{{ResultSetEnumerator}}. To avoid a connection leak, the caller MUST call
{{close()} on the {{ResultSetEnumerator}} when they are finished with it.
Because {{ResultSetEnumerator}} implements {{Enumerator}}, which extends
{{AutoCloseable}}, you can use a try-with-resources block to call {{close()}}
automatically.
If you are calling {{ResultSetEnumerable.iterator()}} (perhaps implicitly, in a
for-each loop) then {{close()}} does not get called, because {{Iterator}} does
not have a {{close()}} method. Be careful of that.
> backend jdbc connection does not returned to connection pool after execute a
> query.
> -----------------------------------------------------------------------------------
>
> Key: CALCITE-1739
> URL: https://issues.apache.org/jira/browse/CALCITE-1739
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: JDK 8
> Reporter: Jingwu Li
> Assignee: Julian Hyde
>
> When we use calcite jdbc adapter to connect to backend database like Oracles,
> after running query, the connection does not get returned to connection pool
> after execution. The apache jdbc dbcp connection pool default max connection
> is 8. So after running a couple times of queries, all connections got used,
> the new request got hang due to not able to get hold of a free connection.
> In org.apache.calcite.runtime.ResultSetEnumerable class
> line 146 statement = null;
> 147 connection = null;
> should we remove those lines so in the finally block the connection.close();
> can be executed?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
