db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject help/advice needed on reference chasing
Date Thu, 02 Mar 2006 01:21:07 GMT
For DERBY-538 I have code to use a class loader, for the application
jars installed in a database, based upon the standard Java
URLClassLoader. The advantages to this are the standard security
features of URLClassLoader are picked up such as signature checking and
Jar sealing.

However, I hit a couple of test failures where a restore from backup
fails because the old database cannot be removed because an open file
cannot be deleted on Windows.

Basically it is a reflection of/related to this Java bug where
URLClassLoader keeps the jar files that it is using open.


The code that fails is from backupRestore.sql
call sqlj.install_jar('extin/brtestjar.jar', 'aggjar', 0);
call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath',
create function dv(P1 INT) RETURNS INT NO SQL external name
'dbytesting.CodeInAJar.doubleMe' language java parameter style java;
select cast (dv(x) as dec(5,2)) from x;

-- empty statrement cache
-- call ec();

----take a backup.
call SYSCS_UTIL.SYSCS_BACKUP_DATABASE('extinout/mybackup');
connect 'wombat;shutdown=true';

---restore a databases
connect 'wombat;restoreFrom=extinout/mybackup/wombat';

The last connect to restore the database is failing.

I can do either of these two things to make the restore work:

  1) don't execute the select with the user's function that is using
code from the aggjar jar file

  2) Uncomment the call to the ec() procedure that empties the statement

Thus the compiled plan is obviously holding onto a reference to the
generated class that in turn has a reference to the
dbytesting.CodeInAJar class that was loaded by the URLClassLoader. This
URLClassLoader has the open file that is the aggjar jar file.

But I can't figure out what is holding onto the statement cache and/or
the compiled plan when the test is failing, I have so far done all of:

    - null out the reference to the statement cache in the language
factory at database shutdown
    - null out references to the URLCLassLoader in the ClassFactory  at
database shutdown
    - checked ij is performing a close on the connection
    - checked the background raw store daemon thread is going away  at
database shutdown
    - executed extra simple queries after the select to ensure ij is not
hanging onto the last ResultSet obtained
    - Looped 100 times on database shutdown, calling System.gc and
System.runFinalization with a 40ms sleep on each iteration

I do see the URLClassLoader being finalized eventually (too late,
several statements later in the script) and with the empty the statement
cache, the URLClassLoader is finalized at database shutdown as one would

Is there any tooling builtin to the JVM to show reference chains, so I
can see at shutdown who is holding onto the generated plan?


View raw message