[
https://issues.apache.org/jira/browse/DERBY-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6440:
---------------------------------
Attachment: derby-6440-01-aa-dropConnectionOnUnload.diff
Attaching derby-6440-01-aa-dropConnectionOnUnload.diff. This patch causes
ForeignDBViews.unloadTool() to remove the connection to the foreign database
from the HashMap managed by ForeignTableVTI. I am running tests now.
Now when you call...
{noformat}
call syscs_util.syscs_register_tool
(
'foreignViews', false,
...
);
{noformat}
...the foreign connection managed by ForeignTableVTI is dropped.
Touches the following files:
--------------
M java/engine/org/apache/derby/vti/ForeignTableVTI.java
Adds two new static methods to this class:
public static void dropConnection( String connectionURL ) - This method drops
the connection associated with the connection url.
public static int countConnections() - This method is useful for verifying how
many connections are still being managed by ForeignTableVTI.
--------------
M java/tools/org/apache/derby/impl/tools/optional/ForeignDBViews.java
Now unloadTool() calls ForeignTableVTI.dropConnection() on its way out.
--------------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/OptionalToolsTest.java
Adds some test cases to verify that syscs_util.syscs_register_tool() drops the
connection on its way out. On exiting, the test_02_foreignDBViews() test
verifies that the ForeignTableVTI._connections HashMap is empty.
> Connections opened by ForeignTableVTI never get released
> --------------------------------------------------------
>
> Key: DERBY-6440
> URL: https://issues.apache.org/jira/browse/DERBY-6440
> Project: Derby
> Issue Type: Bug
> Components: Tools
> Affects Versions: 10.11.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Rick Hillegas
> Attachments: derby-6440-01-aa-dropConnectionOnUnload.diff
>
>
> I noticed during a run of suites.All that one database instance never got
> garbage collected, even after it had been shut down. It turned out it could
> not get garbage collected because it was still referenced from the static
> HashMap _connections in ForeignTableVTI. Looking closer at ForeignTableVTI,
> it looks as if it only calls put() and get() on the HashMap, never remove(),
> so its memory footprint will keep increasing as it is used.
> It would be good to have some way (preferably automatic) of releasing the
> resources held by ForeignTableVTI when they are no longer needed.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
