[
https://issues.apache.org/jira/browse/CASSANDRA-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882591#comment-13882591
]
Benedict commented on CASSANDRA-5549:
-------------------------------------
I'm not totally convinced this is better, but I think I can make it worth with
the off-heap stuff. I think it will get a little ugly, as we'll need two
allocators as well - we'll need some method in the AbstractAllocator interface
to getOffHeapPartner() and getOnHeapPartner(), or something, so that Memtable
can avoid special casing the OffHeapAllocator. But the OnHeapPartner won't
actually support allocating BBs, it will just be for querying and updating
amounts of memory.
Not relishing it, but don't mind pushing it off until we have to address that
problem.
> Remove Table.switchLock
> -----------------------
>
> Key: CASSANDRA-5549
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5549
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jonathan Ellis
> Assignee: Benedict
> Labels: performance
> Fix For: 2.1
>
> Attachments: 5549-removed-switchlock.png, 5549-sunnyvale.png
>
>
> As discussed in CASSANDRA-5422, Table.switchLock is a bottleneck on the write
> path. ReentrantReadWriteLock is not lightweight, even if there is no
> contention per se between readers and writers of the lock (in Cassandra,
> memtable updates and switches).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
