Alright, this is much better. The main thing I’m trying to figure out is that if there is a way to stop the batch if the first statement fails or there is a better pattern/construct for Cassandra to handle that scenario.
- Drew On Mar 18, 2014, at 4:46 AM, Jonathan Lacefield <jlacefi...@datastax.com> wrote: > Okay your question is clear to me know. > > My understanding, after talking this through with some of the engineers here, > is that we have 2 levels of success with batches: > > 1) Did the batch make it to the batch log table? [yes or no] > - yes = success > - no = not success > 2) Did each statement in the batch succeed? [yes or no] > - yes = success > - no = not success > - the case you are interested in. > > If 1 and 2 are both successful - you will receive a success message > if 1 is successful but 2 is not successful (your case) - you will receive a > message stating the batch succeeded but not all replicas are live yet > - in this case, the batch will be retried by Cassandra. This is the > target scenario for atomic batches (to take the burden off of the client app > to monitor, maintain, and retry batches) > - i am going to test this, was shooting for last night but didn't get > to it, to see what actually happens inside the batch > - you could test this scenario with a trace to see what occurs (i.e. if > statement 1 fails is statement 2 tried) > if 1 is not successful then the batch "fails" > - this is because it couldn't make it to the batchlog table for execution > > Hope this helps. I believe this is the best i can do for you at the moment. > > Thanks, > > Jonathan Lacefield > Solutions Architect, DataStax > (404) 822 3487 > > > > > > > On Mon, Mar 17, 2014 at 4:05 PM, Drew Kutcharian <d...@venarc.com> wrote: > I have read that blog post which actually was the source of the initial > confusion ;) > > If I write normally (no batch) at Quorum, then a hinted write wouldn’t count > as a valid write so the write wouldn’t succeed, which means I would have to > retry. That’s a pretty well defined outcome. > > Now if I write a logged batch at Quorum, then a by definition, a hinted write > shouldn’t be considered a valid response, no? > > - Drew > > > On Mar 17, 2014, at 11:23 AM, Jonathan Lacefield <jlacefi...@datastax.com> > wrote: > >> Hello, >> >> Have you seen this blog post, it's old but still relevant. I think it >> will answer your questions. >> http://www.datastax.com/dev/blog/atomic-batches-in-cassandra-1-2. >> >> I think the answer lies in how Cassandra defines a batch "In the context >> of a Cassandra batch operation, atomic means that if any of the batch >> succeeds, all of it will." >> >> My understanding is that in your scenario if either statement succeeded, >> you batch would succeed. So #1 would get "hinted" and #2 would be applied, >> assuming no other failure events occur, like the coordinator fails, the >> client fails, etc. >> >> Hope that helps. >> >> Thanks, >> >> Jonathan >> >> Jonathan Lacefield >> Solutions Architect, DataStax >> (404) 822 3487 >> >> >> >> >> >> >> On Mon, Mar 17, 2014 at 1:38 PM, Drew Kutcharian <d...@venarc.com> wrote: >> Hi Jonathan, >> >> I’m still a bit unclear on this. Say I have two CQL3 tables: >> - user (replication of 3) >> - user_email_index (replication of 3) >> >> Now I create a new logged batch at quorum consistency level and put two >> inserts in there: >> #1 Insert into the “user" table with partition key of a timeuuid of the user >> #2 Insert into the “user_email_index" with partition key of user’s email >> address >> >> As you can see, there is a chance that these two insert statements will be >> executed on two different nodes because they are keyed by different >> partition keys. So based on the docs for Logged Batches, a batch will be >> applied “eventually” in an "all or nothing” fashion. So my question is, what >> happens if insert #1 fails (say replicas are unavailable), would insert #2 >> get applied? Would the whole thing be rejected and return an error to the >> client? >> >> PS. I’m aware of the isolation guarantees and that’s not an issue. All I >> need to make sure is that if the first the statement failed, the whole batch >> needs to fail. >> >> Thanks, >> >> Drew >> >> On Mar 17, 2014, at 5:33 AM, Jonathan Lacefield <jlacefi...@datastax.com> >> wrote: >> >>> Hello, >>> >>> Consistency is declared at the statement level, i.e. batch level when >>> writing, but enforced at each batch row level. My understanding is that >>> each batch (and all of it's contents) will be controlled through a specific >>> CL declaration. So batch A could use a CL of QUORUM while batch B could >>> use a CL of ONE. >>> >>> The detail that may help sort this out for you is that batch statements >>> do not provide isolation guarantees: >>> www.datastax.com/documentation/cql/3.0/cql/cql_reference/batch_r.html. >>> This means that you write the batch as a batch but the reads are per row. >>> If you are reading records contained in the batch, you will read results of >>> partially updated batches. Taking this into account for your second >>> question, you should expect that your read CL will preform as it would for >>> any individual row mutation. >>> >>> Hope this helps. >>> >>> Jonathan >>> >>> Jonathan Lacefield >>> Solutions Architect, DataStax >>> (404) 822 3487 >>> >>> >>> >>> >>> >>> >>> On Sat, Mar 15, 2014 at 12:23 PM, Drew Kutcharian <d...@venarc.com> wrote: >>> Hi Guys, >>> >>> How do Atomic Batches and Consistency Level relate to each other? More >>> specifically: >>> >>> - Is consistency level set/applicable per statement in the batch or the >>> batch as a whole? >>> >>> - Say if I write a Logged Batch at QUORUM and read it back at QUORUM, what >>> can I expect at normal, single node replica failure or double node replica >>> failure scenarios? >>> >>> Thanks, >>> >>> Drew >>> >> >> > >
