Details
Description
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.
Attachments
Attachments
Issue Links
- relates to
-
DERBY-3479 Changed/unexpected query plan when running test 'lang/predicatePushdown.sql'
- Closed
-
DERBY-698 Use Java 5 concurrent collections for better concurrency (rather than synchronized collections)
- Closed
-
DERBY-3092 Use java.util.concurrent in TransactionTable to improve scalability
- Closed