cassandra-commits mailing list archives

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

    [ https://issues.apache.org/jira/browse/CASSANDRA-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874824#comment-13874824
] 

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: 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)

Mime
View raw message