Knut Anders Hatlen wrote: > "Andreas Korneliussen (JIRA)" <derby-dev@db.apache.org> 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.) > Yes.
>> 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. > Seems like a good idea. Andreas
