"Andreas Korneliussen (JIRA)" <[email protected]> writes:
> Assuming the Derby embedded JDBC driver is thread-safe, it should be > safe for a result set to call its own close() method in its > finalizer. If you get a dead-lock in the finalizer, it proves that > it is also possible to write a multithreaded program which gets > deadlocks when calling ResultSet.close, and derby then is not really > MT-safe. > > If this happens, I think it is better to fix the embedded driver so > that it really becomes MT-safe, than avoiding synchronization in the > finalizer threads. There are calls to System.runFinalization() many places in the code. If the thread that invokes System.runFinalization() has obtained the same mutex that a finalize method requires, there can indeed be deadlocks. (But I guess you will argue that we shouldn't call runFinalization() explicitly.) > As for the suggested change in 1142, I would note that If there is > no synchronization in the finalizer, and you set a field in a object > from it, there is no guarantee that other threads will see the > modification of the field (unless, I think, it is > volatile). However, I think Mayuresh has been working on this issue, > so maybe he has tried that approach? FWIW, I tried that approach in my sandbox (setting a volatile variable in GenericLanguageConnectionContext from BaseActivation.markUnused()) and I didn't see the OutOfMemoryError any more. It's a very simple fix, and I don't think the overhead is noticeable, so I'd recommend that we go for that solution. -- Knut Anders
