[ http://issues.apache.org/jira/browse/DERBY-733?page=comments#action_12360463 ]
Daniel John Debrunner commented on DERBY-733: --------------------------------------------- The issue I have with this current patch is that is is localized to one use in RAFContainer, when reading files. Most likely there are other locations where such a facility would be useful, especially on the write for RAFContainer. Are we going to have similar if (java5) statements everywhere. The module api already supports loading different code for different environments, I think that this functionality could be added to the LockManager or maybe a separate module. This would be an improvement, but I think it would be a mistake to have similar code to this patch in many areas of Derby. And yes, maybe we could work on improving Latch performance along these lines. > Starvation in RAFContainer.readPage() > ------------------------------------- > > Key: DERBY-733 > URL: http://issues.apache.org/jira/browse/DERBY-733 > Project: Derby > Type: Improvement > Components: Performance, Store > Versions: 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.2.2 > Environment: Solaris x86 and Linux with Sun JVM 1.5.0. Derby embedded and > client/server. > Reporter: Knut Anders Hatlen > Assignee: Knut Anders Hatlen > Attachments: DERBY-733.diff > > When Derby is completely disk bound, threads might be starved in > RAFContainer.readPage(). This is a real problem when multiple clients > are repeatedly accessing one or a small number of large tables. In > cases like this, I have observed very high maximum response times > (several minutes in the worst cases) on simple transactions. The > average response time is not affected by this. > The starvation is caused by a synchronized block in > RAFContainer.readPage(): > synchronized (this) { > fileData.seek(pageOffset); > fileData.readFully(pageData, 0, pageSize); > } > If many threads want to read pages from the same file, there will be a > long queue of threads waiting for this monitor. Since the Java > specification does not guarantee that threads waiting for monitors are > treated fairly, some threads might have to wait for a long time before > they get the monitor. (Usually, a couple of threads get full throughput > while the others have to wait.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
