On Fri, Aug 17, 2012 at 8:00 AM, Nick Bailey <n...@datastax.com> wrote: > This is actually incorrect. If you get an UnavailableException, the > write was rejected by the coordinator and was not written anywhere.
Last time I checked, this was not true for batch writes. The row mutations were started sequentially (ie, for each mutation check availability, then kick off an aynchronous write), so it was possible for the first to succeed, and the second to fail with an UnavailableException. We had this exact thing happen to us with a custom secondary indexing system, where we wrote the index but not the data, which at the time broke a few assumptions we had made. I would support changing this so that availability is evaluated for all rows in an initial pass, and once that pass has completed there would be no circumstances under which an UnavailableException would be thrown. But the whole thing is of limited value because you could still get a TImedOutException, there's no way around needing to handle the "I don't know what got written" scenario.
