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

[Lionel Elie Mamane]

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:
> >>> On Wed, Jun 03, 2015 at 03:01:39PM +0200, Michael Stahl wrote:
> >>>> On 03.06.2015 14:47, Lionel Elie Mamane wrote:
> > 
> >>>>> Since the problem is essentially that the two threads take the same mutexes
> >>>>> in different order, here is a dirty hack that forces the hsqldb thread
> >>>>> to take the "affine bridge" mutex before taking the "HSQL driver"
> >>>>> mutex.
> > 
> >>>> i'm not entirely sure this is sensible...
> > 
> >>> 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?

-- 
Loinel