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