The atomic batches feature is all about moving the multi-statement application to the server side to avoid having to worry about retry logic on the client side. I'm glad that the client doesn't have to worry about it.
An earlier thread about consistency level and atomic batches broke the execution of atomic batches into two steps (with an assumed final 3rd step): 1) writing the batch to the batch log 2) applying the individual statements in the batch 3) deleting the batch from the batch log The question for me is what #2 does, and what guarantees are in place if the batch execution returns successfully. In addition, I wondered how the consistency level used when executing the batch affects what is done in step #2. >From what I can tell from cassandra server code, there is an additional step >#0, and there are more guarantees than I thought. http://fossies.org/linux/misc/apache-cassandra-2.0.8-src.tar.gz/apache-cassandra-2.0.8-src/src/java/org/apache/cassandra/service/StorageProxy.java#l_537 Here is a revised and enhanced order of operations: a) pre-check replicas for all statements in the batch, assuring that the correct number of nodes are available for the consistency level passed from the client with the batch b) write batch to 2 nodes in the local datacenter, unless you have a single-node datacenter and use CL.ANY, and wait until those writes are complete -- where the batch is written, and how many copies of the batch are written has nothing much to do with the consistency level passed from the client with the batch -- an attempt is made to get two nodes from two separate racks to write the batch c) for each statement in the batch, execute that statement with the consistency level passed from the client with the batch, and wait until the consistency level is satisfied on those writes d) remove the batch from where it had been written, but don't wait This is interesting, because there are a few guarantees here: - step a) implies that no writes (including the batch) will occur if any consistency-level-required replica is unavailable right before starting to submit the writes - step c) implies that all writes will be complete using the consistency level passed with the batch - steps a), b), and c) will be complete BEFORE the batch execution is acknowledged to the client If I've understood this correctly, please let me know. If I've come to the wrong conclusions, please help me understand. John... NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
