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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
