db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-733) Starvation in RAFContainer.readPage()
Date Wed, 30 Nov 2005 16:05:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-733?page=comments#action_12358925 ] 

Knut Anders Hatlen commented on DERBY-733:

I have tried to put calls to the lock() and unlock() methods in the
Java 1.5 ReentrantLock class around the synchronized block. With this
change, the difference between the maximum response time and the
average response time is decreased to an acceptable level.

Since Derby can't rely on features from Java 1.5, we have to implement
our own lock class which works on Java 1.3 and 1.4. This should be
relatively simple. I will try to implement a class which can be used
as a drop-in replacement for java.util.concurrent.locks.ReentrantLock
and test it to be sure that it doesn't pose any significant
overhead. I think the overhead posed by maintaining a queue of waiters
will be small compared to the time it takes to read a page from the

> Starvation in RAFContainer.readPage()
> -------------------------------------
>          Key: DERBY-733
>          URL: http://issues.apache.org/jira/browse/DERBY-733
>      Project: Derby
>         Type: Bug
>   Components: Performance, Store
>     Versions:,,,
>  Environment: Solaris x86 and Linux with Sun JVM 1.5.0. Derby embedded and client/server.
>     Reporter: Knut Anders Hatlen
>     Assignee: Knut Anders Hatlen

> 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:
For more information on JIRA, see:

View raw message