Thu, 16 Mar 2023 11:29:10 -0400, /Clebert Suconic/:
at the end of the test, we call destroy and shutdown of derby with:
try {
DriverManager.getConnection("jdbc:derby:memory:test;destroy=true");
} catch (Exception ignored) {
// it always throws an exception on shutdown
}
try {
DriverManager.getConnection("jdbc:derby:;destroy=true;shutdown=true;destroy=true");
} catch (Exception e) {
So, no matter how hard I try, there is always a memory leak from
DataStore being held at a HashMap, from VFMemoryStorageFactory:tables
I presume. Or there is a "leaked" list (a reference of a reference
somewhere).
I'm not finding destroy=true attribute but a drop=true one:
* Setting attributes for the database connection URL
<https://db.apache.org/derby/docs/10.16/ref/rrefattrib24612.html> (Derby
Reference Manual)
that is specific for in-memory databases. destroy=true is likely doing
nothing but have you logged any possible exception in the catch blocks
to see if Derby isn't actually failing the operation altogether? I'm
always logging the SQLException message (but not the stack trace, if the
SQL code is as expected) in a catch block.
FWIW, I'm using just shutdown=true for a specific in-memory database
instance and not the entire engine (drop=true appears to result in
unwanted time overhead for me) for similar test setup and I haven't
experienced memory leaks. It could be my test suite is not big enough
for me to notice, also.
--
Stanimir
