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 Tue, 04 Sep 2007 12:28:45 GMT

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

Knut Anders Hatlen commented on DERBY-2911:

Since the code added by the patch is disabled, there should be little risk of breaking something.
I therefore committed it with revision 572645. We would need the classes and the stubs regardless
of whether there are comments to the implementation, I think. And you should of course feel
free to test it and comment on it.

The simplest way to test it, is to edit the derby.module.cacheManager property in modules.property
so that it points to ConcurrentCacheFactory instead of ClockFactory, and recompile. I made
that change myself and ran the full JUnit test suite. There was a total of 19 test cases failing
(17 errors + 2 failures). Most of them failed because CacheManager.values() is not implemented
(used by a VTI). I'll investigate the other failures, but it seems at least some of them are
caused by the lack of replacement policy so that objects are left in the cache when the test
expects them to have been thrown out.

> 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-1.diff, d2911-1.stat, 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