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