[ 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