Issue 75168 - More robust Java connection class caching in JConnection.cxx
Summary: More robust Java connection class caching in JConnection.cxx
Status: ACCEPTED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: recent-trunk
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-06 15:36 UTC by Stephan Bergmann
Modified: 2017-05-20 10:48 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2007-03-06 15:36:23 UTC
Issue 69624 on CWS sb36 has for now been fixed by adding a mapping from
classname+classpath to weakly referenced class instances in
connectivity/source/drivers/jdbc/JConnection.cxx:1.2.28.3.  This leaves open a
few questions:

1  The documentation of JNI weak references at
<http://java.sun.com/javase/6/docs/technotes/guides/jni/spec/functions.html#weak>
states "The weak global reference is weaker than Java's internal references to
objects requiring finalization.  A weak global reference will not become
functionally equivalent to NULL until after the completion of the the finalizer
for the referenced object, if present."  For me, that means that if a
java.lang.Class instance referenced by a JNI weak reference had a non-trivial
finalizer, it could happen that the JNI weak reference is successfully
resurrected to a true, non-null JNI reference (via NewLocal/GlobalRef) to a
java.lang.Class instance which is (bound to become) finalized, and which is thus
potentially nonfunctional (if it did something relevant in the finializer).  My
understanding is that this is not an issue, as java.lang.Class is final and is
documented to inherit the trivial finalize of java.lang.Object, but I am not
completely sure about it.

2  In JConnection.cxx, it would probably be better to weakly reference
ClassLoader instances instead of Class instances:  It could be that the given
Class instance has already been garbage collected, but most of what has been
loaded by the ClassLoader, including the ClassLoader itself, is not yet garbage
collected (and will not be for an undefined amount time).  In such a case,
reloading the Class with the old ClassLoader would reuse existing data.  What
has been discussed above under (1) for Class instances would need to be
reevaluated for ClassLoader instances (where ClassLoader is not final, so it is
an open question in how far JNI weak references and finalization would be at odds).

3  In either case (1 and 2) it needs to be evaluated whether it can happen that
JConnection creates a new ClassLoader (as the JNI weak reference is already
null) for which Runtime.load (for the hsqldb native lib, see issue 69624) throws
a UnsatisfiedLinkError because the given native lib is still considered loaded
through the old ClassLoader.  The Java documentation is silent about this.
Comment 1 Stephan Bergmann 2007-03-06 15:38:06 UTC
.
Comment 2 Marcus 2017-05-20 10:48:09 UTC
Reset assigne to the default "issues@openoffice.apache.org".