db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode
Date Mon, 21 Aug 2006 18:38:01 GMT
"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.)

> 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

View raw message