You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Cathy Daw (Commented) (JIRA)" <ji...@apache.org> on 2012/01/20 03:39:40 UTC

[jira] [Commented] (CASSANDRA-2893) Add row-level isolation

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

Cathy Daw commented on CASSANDRA-2893:
--------------------------------------

I have a question about the test case attached: row_isolation_test.py

Based on how the inserts or deletes are constructed, if I continually poll the column count of the test key, while a large mutation is being applied, the only value I should see if this transaction is isolated is 0, 100 or 200k. Otherwise, I print an error message (this is my version of a 'diff').

Running this script on different versions, I saw the following behavior.  I am not sure if the experiment is wrong, or if I have a bug because my expectation would be to see no diffs (or messages from the 2nd thread).
* 0.8.6: incremental column counts on the large column delete and insert (expected)
* 1.0.7: incremental column counts on the large column delete (expected to see insert diffs as well)
* 1.0 branch: incremental column counts on the large column delete (no diffs expected)
* trunk: incremental column counts on the large column delete (no diffs expected)

*0.8.9 test run* 
{code}
Thread 1: Insert to 100 - Start
Thread 1: Insert End - Expect # columns = 100
Thread 1: Insert to 200k - Start
Thread 1: Insert End - Expect # columns = 200000
Thread 1: Remove 200k - Start
--- Thread 2: Mismatch Column Count.  Current # columns: 184628 Current Test: test3 - remove 200k
--- Thread 2: Mismatch Column Count.  Current # columns: 44765 Current Test: test3 - remove 200k
Thread 1: Remove End - Expect # columns = 0
Thread 1: Insert to 100 - Start
Thread 1: Insert End - Expect # columns = 100
Thread 1: Remove 100 - Start
Thread 1: Remove End - Expect # columns = 0
Thread 1: Insert 100k to 300k - Start
--- Thread 2: Mismatch Column Count.  Current # columns: 569 Current Test: test5 - insert 200k
Thread 1: Insert End - Expect # columns = 200000
{code}


                
> Add row-level isolation
> -----------------------
>
>                 Key: CASSANDRA-2893
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2893
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.1
>
>         Attachments: 0001-Move-deletion-infos-into-ISortedColumns-v2.patch, 0001-Move-deletion-infos-into-ISortedColumns.patch, 0002-Make-memtable-use-CF.addAll-v2.patch, 0002-Make-memtable-use-CF.addAll.patch, 0003-Add-AtomicSortedColumn-and-snapTree-v2.patch, 0003-Add-AtomicSortedColumn-and-snapTree.patch, latency-plain.svg, latency.svg, row_isolation_test.py, snaptree-0.1-SNAPSHOT.jar
>
>
> This could be done using an the atomic ConcurrentMap operations from the Memtable and something like http://code.google.com/p/pcollections/ to replace the ConcurrentSkipListMap in ThreadSafeSortedColumns.  The trick is that pcollections does not provide a SortedMap, so we probably need to write our own.
> Googling [persistent sortedmap] I found http://code.google.com/p/actord/source/browse/trunk/actord/src/main/scala/ff/collection (in scala) and http://clojure.org/data_structures#Data Structures-Maps.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira