[ http://issues.apache.org/jira/browse/DERBY-733?page=comments#action_12360447 ]
Daniel John Debrunner commented on DERBY-733: --------------------------------------------- I wonder if we can use the existing lock manager, which provides predictable queueing behaviour on granting locks, rather than add a new mechansm. > 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
