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