Please start separate threads for separate questions- you have more chances of getting an answer.
On Sun, May 27, 2012 at 1:55 PM, Lance Norskog <goks...@gmail.com> wrote: > Please start separate threads for separate q > > On Fri, May 25, 2012 at 6:30 AM, Nicholas Ball > <nicholas.b...@nodelay.com> wrote: >> >> Hey all, >> >> I have another question with regards to this thread. >> >> Does anyone know what the state is of the rollback command in 4.0 and how >> it works with both; replicas (i.e. distributed rollbacks) and the snapshot >> isolation implemented (i.e. timestamps reverted?), the relevant class is >> DistributedUpdateProcessor but not sure if I'm missing something. Has this >> been implemented? >> >> Cheers, >> Nicholas >> >> On Thu, 24 May 2012 09:53:23 -0600, Nicholas Ball >> <nicholas.b...@nodelay.com> wrote: >>> Thanks for the link, will investigate further. On the outset though, it >>> looks as though it's not what we want to be going towards. >>> Also note that it's not open-sourced (other than Solandra which hasn't >>> been updated in aaaages https://github.com/tjake/Solandra). >>> >>> Rather than build on top of Cassandra, the new NRT + transaction log >> Solr >>> features really make it more of a possibility to make Solr into a >>> NoSQL-like system and possibly with better transactional guarantees than >>> NoSQL! >>> >>> Speaking to yonik has given me more information on this. Currently, >> there >>> is an optimistic lock-free mechanism on a per-document basis only as for >>> most, documents only live on a single logical shard. It essentially >> checks >>> the _version_ you send in for a document against the latest version for >> the >>> document it has. >>> >>> I propose an additional feature to this for those who want to have such >>> guarantees spanning over multiple documents living on various shards. In >> my >>> use-case, I have shards holding documents that point to other shards. In >>> this case, an update would need to be an atomic transaction spanning >> over >>> various documents on various shards. Would anyone object to having this >>> functionality added to Solr if I were to contribute it? >>> >>> Many thanks, >>> Nicholas >>> >>> On Thu, 24 May 2012 08:16:25 -0700, Walter Underwood >>> <wun...@wunderwood.org> wrote: >>>> You should take a look at what DataStax has already done with Solr and >>>> Cassandra. >>>> >>>> >> http://www.datastax.com/dev/blog/cassandra-with-solr-integration-details >>>> >>>> wunder >>>> >>>> On May 24, 2012, at 7:50 AM, Nicholas Ball wrote: >>>> >>>>> >>>>> Hey all, >>>>> >>>>> I've been working on a SOLR set up with some heavy customization >> (using >>>>> the adminHandler as a way into the system) for a research project @ >>>>> Imperial College London, however I now see there has been a >> substantial >>>>> push towards a NoSQL. For this, there needs to be some kind of >>>>> optimistic >>>>> fine-grained concurrency control on updates. As we have document >>>>> versioning >>>>> in-built into Lucene (and therefore Solr) this shouldn't be too >>>>> difficult, >>>>> however the push has been more of a focus on single core optimistic >>>>> LOCKING. >>>>> >>>>> I would like to take this toward a multi-core (and multi-node) >>>>> distributed >>>>> optimistic lock-free mechanism. This is gives us the ability to >> provide >>>>> stronger guarantees than NoSQL wrt distributed transaction isolation >>> and >>>>> as >>>>> we can now do soft-commits, we can also provide specific version >>>>> rollbacks >>>>> (http://java.dzone.com/articles/exploring-transactional-0). Some more >>>>> interesting reading on this topic: (read-)snapshot isolation >>>>> (http://pages.cs.wisc.edu/~cs764-1/critique.pdf) and even stronger >>>>> guarantees with a slight performance hit with write-snapshot isolation >>>>> (http://www.fever.ch/usbkey_eurosys12/papers/p155-yabandehA.pdf). >>> People >>>>> are starting to realize that we don't have to sacrifice guarantees for >>>>> better performance and scalability (like NoSQL) but rather relax them >>>>> very >>>>> minimally. >>>>> >>>>> What I need is for someone to shed some light on this feature and the >>>>> future plans of Solr wrt this is? Am I correct in thinking that a >>>>> multiversion concurrency control (MVCC) locking mechanism now exist >> for >>> a >>>>> single core or is it lock-free and multi-core? >>>>> >>>>> Many thanks, >>>>> Nicholas Ball (aka incunix) >>>> >>>> -- >>>> Walter Underwood >>>> wun...@wunderwood.org > > > > -- > Lance Norskog > goks...@gmail.com -- Lance Norskog goks...@gmail.com
