On 11/09/2016 23:07, Ryan Svihla wrote: > 1. A batch with updates to a single partition turns into a single > mutation so partition writes aren't possible (so may as well use > Unlogged batches) > 2. Yes, so use local_serial or serial reads and all updates you want to > honor LWT need to be LWT as well, this way everything is buying into the > same protocol and behaving accordingly. > 3. LWT works with batch (has to be same partition). > https://docs.datastax.com/en/cql/3.1/cql/cql_reference/batch_r.html if > condition doesn't fire none of the batch will (same partition will mean > it'll be the same mutation anyway so there really isn't any magic going on).
Is there a good reason for linking to the 3rd party docs rather than the official docs in this case? I can't see one at the moment. The official docs appear to be: http://cassandra.apache.org/doc/latest/cql/dml.html#batch It might not matter in this particular instance but it looks as if there is a little more to the syntax than the 3rd party docs suggest (even if you switch to the latest version of those 3rd party docs). Generally, if you are going to point to docs, please point to the official Apache Cassandra docs unless there is a very good reason not to. (And if the good reason is that there’s a deficiency in the Apache Cassandra docs, please make it known on the list or in a Jira so someone can write what’s missing) Mark > Your biggest issue with such a design will be contention (as it would > with an rdbms with say row locking), as by intent you're making all > reads and writes block until any pending ones are complete. I'm sure > there are a couple things I forgot but this is the standard wisdom. > > Regards, > > Ryan Svihla > > On Sep 11, 2016, at 3:49 PM, Jens Rantil <jens.ran...@tink.se > <mailto:jens.ran...@tink.se>> wrote: > >> Hi, >> >> This might be off-topic, but you could always use Zookeeper locking >> and/or Apache Kafka topic keys for doing things like this. >> >> Cheers, >> Jens >> >> On Tuesday, September 6, 2016, Bhuvan Rawal <bhu1ra...@gmail.com >> <mailto:bhu1ra...@gmail.com>> wrote: >> >> Hi, >> >> We are working to solve on a multi threaded distributed design >> which in which a thread reads current state from Cassandra (Single >> partition ~ 20 Rows), does some computation and saves it back in. >> But it needs to be ensured that in between reading and writing by >> that thread any other thread should not have saved any operation >> on that partition. >> >> We have thought of a solution for the same - *having a write_time >> column* in the schema and making it static. Every time the thread >> picks up a job read will be performed with LOCAL_QUORUM. While >> writing into Cassandra batch will contain a LWT (IF write_time is >> read time) otherwise read will be performed and computation will >> be done again and so on. This will ensure that while saving >> partition is in a state it was read from. >> >> In order to avoid race condition we need to ensure couple of things: >> >> 1. While saving data in a batch with a single partition (*Rows may >> be Updates, Deletes, Inserts)* are they Isolated per replica node. >> (Not necessarily on a cluster as a whole). Is there a possibility >> of client reading partial rows? >> >> 2. If we do a LOCAL_QUORUM read and LOCAL_QUORUM writes in this >> case could there a chance of inconsistency in this case (When LWT >> is being used in batches). >> >> 3. Is it possible to use multiple LWT in a single Batch? In >> general how does LWT performs with Batch and is Paxos acted on >> before batch execution? >> >> Can someone help us with this? >> >> Thanks & Regards, >> Bhuvan >> >> >> >> -- >> Jens Rantil >> Backend engineer >> Tink AB >> >> Email: jens.ran...@tink.se <mailto:jens.ran...@tink.se> >> Phone: +46 708 84 18 32 >> Web: www.tink.se <http://www.tink.se/> >> >> Facebook <https://www.facebook.com/#!/tink.se> Linkedin >> <http://www.linkedin.com/company/2735919?trk=vsrp_companies_res_photo&trkInfo=VSRPsearchId%3A1057023381369207406670%2CVSRPtargetId%3A2735919%2CVSRPcmpt%3Aprimary> >> Twitter >> <https://twitter.com/tink> >>
