[
https://issues.apache.org/jira/browse/CASSANDRA-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne resolved CASSANDRA-3856.
-----------------------------------------
Resolution: Not A Problem
I agree with Jonathan, if persistent collection make sense for a ticket, let's
use them there and/or have the discussion of how pertinent they are for that
use case there.
> consider using persistent data structures for some things
> ---------------------------------------------------------
>
> Key: CASSANDRA-3856
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3856
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Peter Schuller
> Assignee: Peter Schuller
> Priority: Minor
>
> When thinking about CASSANDRA-3831, CASSANDRA-3833, CASSANDRA-3417 (and
> probably others) I keep thinking that I really want persistent data
> structures ala Clojure to enable giving out stable copies of data without
> copying, to avoid complicating the code significantly to achieve a
> combination of reasonable computational complexity, performance, and
> thread-safety. However, I am not about to propose that we introduce Clojure
> into the code base.
> Turns out other people have had similar desires and wanted to see Java
> varsions of the clojure data structures (https://github.com/krukow/clj-ds and
> http://thesoftwarelife.blogspot.com/2009/10/java-immutable-persistent-map.html)
> and there is another persistent ds project too
> (http://code.google.com/p/pcollections/).
> The latter in particular looks interesting (not having tested it).
> I think it's worth considering adopting the use of these for things like the
> token meta data. In general, I'd say it may be worth considering for things
> that are not performance critical in the sense of constant factor
> performance, but where you want thread-safety and reasonable computational
> complexity and an easier sense of what's safe from a concurrency perspective.
> Currently, we keep having to either copy data to "punt" a concurrency
> concern, at the cost of computational complexity, or else add locking at the
> cost of performance and complexity, or switch to concurrent data structures
> at the cost of performance and another type of complexity.
> Does this seem completely out of the blue to people or do people agree it's
> worth exploring?
--
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
