help needed: hsqldb shutdown race condition, how to fix without deadlock

[Michael Stahl]

On 09.06.2015 15:23, Lionel Elie Mamane wrote:
> On Tue, Jun 09, 2015 at 03:05:57PM +0200, Michael Stahl wrote:
>> On 09.06.2015 14:33, Lionel Elie Mamane wrote:
>>> On Wed, Jun 03, 2015 at 11:08:36PM +0200, Michael Stahl wrote:
>>>> On 03.06.2015 17:31, Lionel Elie Mamane wrote:
>>>>> Thinking the issue from yet another angle, if we go back to the
>>>>> situation at the start of this thread (hsqldb is *not* affine). I
>>>>> don't understand why the
>>>>> connectivity::hsqldb::ODriverDelegator::disposing thread holds the
>>>>> affine lock, and goes through the affine bridge:
>>>
>>>>> Why does the call from dbaccess::OConnection::disposing into
>>>>> connectivity::hsqldb::ODriverDelegator::disposing go through the
>>>>> affine bridge?
>>>
>>>> because OConnection is outside the affine environment, so it has to go
>>>> through the bridge to call a component inside the affine environment.
>>>
>>>> however the ODriverDelegator isn't inside the affine environment, what
>>>> happens is that while AffineBridge::v_callInto_v() waits for the call on
>>>> the "inner" thread to return, it assigns the current (calling) thread as
>>>> the "outer" thread and in AffineBridge::outerDispatch() it waits for
>>>> outgoing calls from the "inner" thread.
>>>
>>> You discuss what happens when the call goes into the affine bridge. I
>>> don't understand why it goes through the affine brige in the first
>>> place.
>>
>> presumably because OConnection::disposing() is calling XConnection
>> methods that are implemented by class java_sql_Connection in the JDBC
>> driver.
> 
> Oh, you mean:
> 
> In thread 3, OConnection::disposing() is calling something that is
> implemented by class java_sql_Connection in the JDBC driver. I'll
> assume for that it is the "close" method.
> 
> java_sql_Connection::close is executed in another thread (e.g. thread
> 4) because JDBC declared thread affine, and in thread 4 calls
> connectivity::hsqldb::ODriverDelegator::disposing. *That* call in
> thread 4 is messaged to thread 3 to be executed in thread 3.
> 
> That's why the backtrace in thread 3 shows a call from
> OConnection::disposing() to
> connectivity::hsqldb::ODriverDelegator::disposing, but that actually
> goes through java_sql_Connection::close (and
> java_sql_Connection::dispose and java_sql_Connection::disposing) in
> thread 4.
> 
> Did I understand correctly now?

yes, that's how it works.