db-derby-dev mailing list archives

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

>> 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.


View raw message