db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1704) Allow more concurrency in the lock manager
Date Tue, 13 Feb 2007 19:56:44 GMT
"Anders Morken (JIRA)" <jira@apache.org> writes:

> Anders Morken commented on DERBY-1704:
> --------------------------------------
> In slightly related work, we've recently done a little testing with
> a single-record select load on a trunk patched with DERBY-2107 as
> well as a port of the patches to split the hash tables in the lock
> subsystem that you included here.
> With a separate table and index for each thread (to remove latch
> contention and lock waits from the equation) we got an overall
> throughput increase of about 16% compared to a "single table for all
> threads" run (given a cache large enough to maintain the database
> in-memory), and 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 - and validates the "split
> hashtable" approach for this workload. =)

Thank you for running the tests and posting your findings! I think
you're right that Clock will be the next bottleneck for multi-threaded
applications. It's a big hash table which all threads need to
synchronize on, very similar to the current lock manager.

Knut Anders

View raw message