db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-733) Starvation in RAFContainer.readPage()
Date Fri, 16 Dec 2005 19:36:50 GMT
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.)
> 
> 


Mime
View raw message