[
https://issues.apache.org/jira/browse/CASSANDRA-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174948#comment-13174948
]
Sylvain Lebresne commented on CASSANDRA-2893:
---------------------------------------------
bq. should we just get rid of AbstractColumnContainer now since it's basically
just a wrapper around ISortedColumns?
It's still useful to factor the code between ColumnFamily and SuperColumn. If
we remove it, we'll basically have to duplicate ACC into both CF and SC. But
I'll be more than happy to remove it when/if we remove SCs :P
bq. Doesn't Guava Functions.identity do the same as ACC.identity?
Totally, I guess I don't know Guava too well. I'll replace it.
bq. I wonder if this is premature optimization or even counterproductive for
the uncontended case. Did you do any testing around this?
To be honest, I did not test it. But the rational is that I would be surprised
if checking an atomic ref get (even on each iteration) has any kind of visible
impact (compared to adding a column to a snaptree), while I have no doubt that
in the contended case with non trivially small batches not doing this will have
a visible impact. That was more about trading a probably non-noticeable hit on
non-contended to avoid any bad outliers.
I also though about doing the the reference check only every few iterations,
but I figured that would likely don't change anything since again an atomic ref
get should be really fast.
But obviously it doesn't cost much to check those assumptions and I'll do some
testing.
I'll also note that we could easily change snaptree by a persistent sorted map.
This could be faster than snaptree because there would be any internal
synchronization (while snaptree has internal synchronization, that we mostly
don't use, except for the fact that they allow a concurrently safe
copy-on-write). I have a persistent store map implementation almost ready so
I'll probably do that test at some point, but if we think snaptree is
acceptable I suggest we go with that at first since it is absolutely unclear
the persistent sorted map will be faster (it will generate more garbage for
instance) and I'm sure how long it will take to do such a test.
> 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, 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
