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] Updated: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes
Date Wed, 29 Aug 2007 11:51:31 GMT

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

Knut Anders Hatlen updated DERBY-2911:

    Attachment: d2911-unused.stat

I noticed that some of the methods in CacheFactory/CacheManager are not used. As a first step
before starting on a new cache manager, I would like to remove those methods from the interfaces
(but I will leave the actual implementations in Clock untouched for now). This way we can
avoid having two implementations of something that's never used. We can always implement some
of the methods later, if we ever need them, but I think it is better to wait until the need
arises, rather than to guess now what we might need in the future.

The methods that are not used, are:


getCacheStats() and resetCacheStats() are called by other methods (simple forwarding methods),
but those methods are never called. The attached patch (d2911-unused) removes all the unused
methods, including the methods that call getCacheStats() and resetCacheStats(). suites.All
passed. I have also started a derbyall run which has not completed yet.

> 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:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d2911-unused.diff, d2911-unused.stat
> 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.

View raw message