Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


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.



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.