To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=75168 Issue #|75168 Summary|More robust Java connection class caching in JConnecti |on.cxx Component|Database access Version|current Platform|All URL| OS/Version|All Status|NEW Status whiteboard| Keywords| Resolution| Issue type|ENHANCEMENT Priority|P3 Subcomponent|none Assigned to|sb Reported by|sb
------- Additional comments from [EMAIL PROTECTED] Tue Mar 6 15:36:23 +0000 2007 ------- 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. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
