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
<http://www.linkedin.com/in/jlacefield>
<http://www.datastax.com/what-we-offer/products-services/training/virtual-training>
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
> batchsucceeds, 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
> <http://www.linkedin.com/in/jlacefield>
>
>
> <http://www.datastax.com/what-we-offer/products-services/training/virtual-training>
>
>
> 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
>> <http://www.linkedin.com/in/jlacefield>
>>
>>
>>
>> <http://www.datastax.com/what-we-offer/products-services/training/virtual-training>
>>
>>
>> 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
>>
>>
>>
>>
>
>
