title: Cassandra WriteTimeoutException handling during CAS operations
body: <p>The questions are regarding the “CAS operations” paragraph into the article : <a href="http://www.datastax.com/dev/blog/cassandra-error-handling-done-right" rel="nofollow">http://www.datastax.com/dev/blog/cassandra-error-handling-done-right</a> </p>
  
  <p>a)</p>
  
  <blockquote>
    <p>If the paxos phase fails, the driver will throw a WriteTimeoutException with a WriteType.CAS as retrieved with WriteTimeoutException#getWriteType(). In this situation you can’t know if the CAS operation has been applied..</p>
  </blockquote>
  
  <p>How do you understand this?</p>
  
  <p>I thought that If the paxos (prepare) phase fails then the coordinator will not initiate the commit phase at all?
  I guess that it does not matter how the paxos phase fails (not enough replicas or replica timeouts or ..).</p>
  
  <p>b)</p>
  
  <blockquote>
    <p>The commit phase is then similar to regular Cassandra writes… you can simply ignore this error if you make sure to use setConsistencyLevel(ConsistencyLevel.SERIAL) on the subsequent read statements on the column that was touched by this transaction, as it will force Cassandra to commit any remaining uncommitted Paxos state before proceeding with the read</p>
  </blockquote>
  
  <p>Wondering about the above with relation to writes with ConsistencyLevel.QUORUM: </p>
  
  <p>If the commit phase failed because there is no quorum (unavailable nodes or timeouts) then we get back WriteTimeoutException with a WriteType of SIMPLE, right?
  In this case it is not clear if the write is actually successful or not, right?
  So I’m not sure what are all the possibilities from now on (recover/rollback/nothing)?</p>
  
  <p>Is it saying that if I use ConsistencyLevel.QUORUM for the read operation I can see the old data version (as if the above write was not successful) for some time and after that again with QUORUM read I will see that the write is successful?
  (actually I’m seen exactly this in a 3 node cluster with replication factor=3 after WriteTimeoutException (2 replica were required but only 1 acknowledged the write) – quorum read just after that returned the old data and then when i check with cqlsh I see the new data).</p>
  
  <p>How this is possible?
  guess:
  Probably after the timeout the coordinator says that we have no quorum for the commit phase <em>yet</em> (and subsequent QUORUM reads get the older data version) and returns the WriteTimeoutException.type=SIMPLE to the client. And when the nodes that have timeout actually respond/commit we have a quorum in this future moment and after it all quorum reads will obtain the newer data version.
  But not sure about the explanation of when you use read with SERIAL.</p>