[
https://issues.apache.org/jira/browse/DERBY-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5623:
--------------------------------------
Attachment: d5623-1.diff
Thanks for the patch, David. I had played with a similar patch myself (see the
attached file, d5623-1.diff). My patch differs a little from your patch:
- It preserves the synchronization in getDaemonThread(). Without
synchronization in that method, I saw occasional IllegalThreadStateExceptions
when booting and shutting down databases concurrently in many threads.
- It uses PrivilegedAction instead of PrivilegedExceptionAction for the actions
that don't throw checked exceptions, which made the exception handling simpler.
All the regression tests passed with this patch.
I also ran an application that booted 1000 databases in 20 threads on a machine
with 8 cores, and the patch seemed to speed it up by 3-4%. It was primarily the
removal of synchronization in getJVMProperty() that contributed to the speed-up.
Although the speed-up is modest (at least in my environment) the patches remove
more lines of code than they add, which is a good thing in itself.
> Loosen up synchronization in FileMonitor
> ----------------------------------------
>
> Key: DERBY-5623
> URL: https://issues.apache.org/jira/browse/DERBY-5623
> Project: Derby
> Issue Type: Improvement
> Components: Services
> Affects Versions: 10.8.2.2
> Reporter: Knut Anders Hatlen
> Attachments: d5623-1.diff, derby-diff.txt
>
>
> When opening a large number of databases in parallel, many threads get stuck
> for a long time in FileMonitor, as reported in this thread on derby-user:
> http://mail-archives.apache.org/mod_mbox/db-derby-user/201202.mbox/%3CCAEQ8c00vx0yFrwWyjm%3Dt_Yd%2BuuKGOL%3DSgpYfQuYghOOPgdN8-w%40mail.gmail.com%3E
> The synchronization in FileMonitor is only needed because the monitor
> instance is also used as a shared PrivilegedExceptionAction instance. Since
> all databases share one FileMonitor instance, threads that access any of
> these methods are serialized. If each method created its own PrivilegedAction
> or PrivilegedExceptionAction instance instead of using the monitor's run()
> method, these methods wouldn't need synchronization.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
