[
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
d2911-unused.diff
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:
CacheFactory.newSizedCacheManager()
CacheManager.getMaximumSize()
CacheManager.resize()
CacheManager.containsKey()
CacheManager.setUsed()
CacheManager.getNumberInUse()
CacheManager.getCacheStats()
CacheManager.resetCacheStats()
CacheManager.scan()
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: 10.4.0.0
> 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.
