[DERBY-2911] Implement a buffer manager using java.util.concurrent classes

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 10.4.1.3
• Fix Version/s: 10.4.1.3
• Component/s: Services
• Bug behavior facts: Performance
• Assignee: Knut Anders Hatlen
• Reporter: Knut Anders Hatlen
• Created: 06/Jul/07 09:51
• Updated: 29/Jun/09 14:07
• Resolved: 01/Apr/08 09:05

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.

Issue Links

• relates to: DERBY-3479 Changed/unexpected query plan when running test 'lang/predicatePushdown.sql'
• relates to: DERBY-698 Use Java 5 concurrent collections for better concurrency (rather than synchronized collections)
• relates to: DERBY-3092 Use java.util.concurrent in TransactionTable to improve scalability