db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes
Date Fri, 21 Sep 2007 07:56:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529330
] 

Knut Anders Hatlen commented on DERBY-2911:
-------------------------------------------

Committed d2911-5 with revision 578006.

When I reran suites.All and derbyall with the new buffer manager enabled after applying this
patch, I only saw the expected failures in suites.All and two failures in derbyall.

To find out which of the failures that are to be expected when the buffer manager has no replacement
algorithm, I ran the regression tests with the old buffer manager modified so that the replacement
algorithm wasn't used (that is, I hard coded the Clock.maximumSize to Integer.MAX_VALUE).
Then I saw the same failures in suites.All, but only one failure in derbyall. That leaves
us with one "unexplained" error: unit/T_RawStoreFactory.unit which runs out of time.

> Implement a buffer manager using java.util.concurrent classes
> -------------------------------------------------------------
>
>                 Key: DERBY-2911
>                 URL: https://issues.apache.org/jira/browse/DERBY-2911
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance, Services
>    Affects Versions: 10.4.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d2911-1.diff, d2911-1.stat, d2911-2.diff, d2911-3.diff, d2911-4.diff,
d2911-5.diff, d2911-entry-javadoc.diff, d2911-unused.diff, d2911-unused.stat, d2911perf.java
>
>
> There are indications that the buffer manager is a bottleneck for some types of multi-user
load. For instance, Anders Morken wrote this in a comment on DERBY-1704: "With a separate
table and index for each thread (to remove latch contention and lock waits from the equation)
we (...) found that org.apache.derby.impl.services.cache.Clock.find()/release() caused about
5 times more contention than the synchronization in LockSet.lockObject() and LockSet.unlock().
That might be an indicator of where to apply the next push".
> It would be interesting to see the scalability and performance of a buffer manager which
exploits the concurrency utilities added in Java SE 5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message