On Thu, 2012-01-12 at 10:44 +0100, Stephan Bergmann wrote:
I think the best solution here would be to change the LibO hsqldb code,
to call Attach/DetachCurrentThread rarely rather than frequently, but
according to Ocke Janssen (who used to maintain that code) that was no
easy option.
One rather easy fix would be to confine the
com.sun.star.comp.sdbc.JDBCDriver UNO code to a thread-affine apartment,
see the attached patch. That way, all code related to this UNO service
(which is the code that calls Attach/DetachCurrentThread so frequently
and thus causes the performance degradation) is run in a single,
dedicated thread.
That sounds like a rather elegant fix to me :-) as long as that thread
is not the "main thread" - we use rather deep stacks in the calc code
there & this is how the original bug was found etc. it'd be a good fix.
One drawback of using the thread-affine apartment is that all code
related to the JDBC driver is effectively serialized, removing any
potential performance advantage from accessing the driver from multiple
treads. I do not know whether that is acceptable or not.
Given the generally tangled locking everywhere I would expect that
virtually everything is serialised anyway ;-) so ...
It'd be great to have a fix for the base guys I guess.
Thanks !
Michael.
--
michael.meeks@suse.com <><, Pseudo Engineer, itinerant idiot
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.