[
https://issues.apache.org/jira/browse/CASSANDRA-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751824#action_12751824
]
Jonathan Ellis commented on CASSANDRA-414:
------------------------------------------
I checked the source for NBHM and couldn't find any evidence that my literal
reading of the iterator contract ("Iterators and Enumerations return elements
reflecting the state of the hash table at some point at or since the creation
of the iterator/enumeration") was correct. So I asked the author for
clarification here: https://sourceforge.net/forum/message.php?msg_id=7611241.
He replied, and sure enough, Jun's suspicions were correct and even if the
compaction thread is careful to add the new SSTR before removing the old ones
from sstables_, iterator threads may see the absence of the latter but not the
presence of the former.
So I think that this approach is not going to work. But I think we can still
cut the lock penalty dramatically from what it is now. I should have some code
for that approach Monday.
> remove sstableLock
> ------------------
>
> Key: CASSANDRA-414
> URL: https://issues.apache.org/jira/browse/CASSANDRA-414
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments:
> 0001-CASSANDRA-414-combine-addToList-and-storeLocation-ren.txt,
> 0001-CASSANDRA-414-combine-addToList-and-storeLocation-ren.txt,
> 0002-remove-sstableLock.-re-order-a-few-ops-so-that-we-can.txt,
> 0002-remove-sstableLock.-re-order-a-few-ops-so-that-we-can.txt
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
