You have raised some issues about this patch. In the apache
commit/review model should I be raising a vote on the patch. I
think this is basically do you feel strongly enough to vote -1
on such a vote.
I don't think Knut plans on building a separate module for this
locking stuff, at least not until it is used in more than one place.
He should comment.
I am ok with the patch, and would go foward with his subsequent
patch recently submitted as it addressed some of my concerns (I have
not had a chance yet to review it). I agree the separate module approach is
better, but that is not what was submitted. I believe I would
not commit a proliferation of the same kinds of changes in multiple
files.
I am hoping that this patch leads to more work in this area, identifying
the next bottleneck and next change and it may become clearer what major
changes need to happen.
Daniel John Debrunner (JIRA) wrote:
[ 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.)
