DERBY-6619 After silently swallowing SecurityExceptions, Derby can leak class loaders

Backported from trunk svn 1620385.

Patch derby-6619-2-refinement which implements the following
refinements to the test to avoid changing the context class loader in
SingletonTimerFactory (suggested by Knut):

The orginal test tested against the system class loader. This new
patch will:

1) Check if the context class loader is the same as the loader of the
SingletonTimerFactory class (that is, the class loader from which
Derby classes are loaded). Even if this isn't the same as the system
class loader, it would be safe to skip the workaround for DERBY-3745,
since the class loader for the Derby classes would not be eligible for
garbage collection until the engine is shut down anyway. This would
prevent some more false positives from being reported in
derby.log. I'd assume this is a kind of false positive that could
easily occur in an application server environment where the Derby
classes are not found on the system class loader.

2) Check against Thread.class.getClassLoader() instead of
ClassLoader.getSystemClassLoader(). Normally, those two checks would
be identical. If however the setup is such that they aren't identical,
we'd still know that the class loader actually used for system classes
such as the Thread class would have to stay in memory for as long as
the timer thread is alive, regardless of the context class loader of
the thread, so the workaround for DERBY-3745 can be skipped if it's
the same as the context class loader. The check will be a bit more
specific this way.



git-svn-id: https://svn.apache.org/repos/asf/db/derby/code/branches/10.11@1620392 13f79535-47bb-0310-9956-ffa450edef68