cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5549) Remove Table.switchLock
Date Fri, 17 Jan 2014 14:26:22 GMT


Benedict commented on CASSANDRA-5549:

issue() is the normal parlance when talking about memory fences, in my experience, which this
is roughly a high level model of, so I would like to keep it. However we could go with partition()?
Or I can wrack my brains some more...

OpOrdering -> OpOrder is good. I'm definitely with you on Group as well, now.

I'm not fond of includes(). Maybe isAfter()?

> Remove Table.switchLock
> -----------------------
>                 Key: CASSANDRA-5549
>                 URL:
>             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

View raw message