> Can you outline the detailed steps to reproduce the issue Yuji ? > Our application requests UPDATE a row. The row has "id"(PRIMARY KEY), "revision" and "value" columns. The updating condition is EQ of current "revision".
When the problem happens, the following sequence is executed in one thread. But a lot of threads request read/write to Cassandra concurrently. So, all nodes have high load. 1. request updating a row with new revision and value 2. WriteTimeoutException with WriteType.SIMPLE occurs 3. read the row to repair with ConsistencyLevel.SERIAL 4. the read succeeds. But the result isn't new value This problem does not always occurs. Almost read can get the latest value. Thanks Yuji On Mon, Jul 25, 2016 at 4:34 PM, DuyHai Doan <doanduy...@gmail.com> wrote: > Can you outline the detailed steps to reproduce the issue Yuji ? > > On Mon, Jul 25, 2016 at 3:16 AM, Yuji Ito <y...@imagine-orb.com> wrote: > >> thanks, Ryan >> >> >>> are you using one of the SERIAL Consistency Levels? >> >> yes, I use read with ConsistencyLevel.SERIAL. >> >> On Mon, Jul 25, 2016 at 10:10 AM, Ryan Svihla <r...@foundev.pro> wrote: >> >>> are you using one of the SERIAL Consistency Levels? >>> >>> -- >>> Ryan Svihla >>> >>> On July 24, 2016 at 8:08:01 PM, Yuji Ito (y...@imagine-orb.com) wrote: >>> >>>> Hi, >>>> >>>> I have another question about CAS operation. >>>> >>>> Can a read get stale data after failure in commit phase? >>>> >>>> According to the following article, >>>> when a write fails in commit phase (a WriteTimeout with WriteType >>>> SIMPLE happens), >>>> a subsequent read will repair the uncommitted state >>>> and get the latest data which the write tried to update. >>>> >>>> Ref. >>>> http://www.datastax.com/dev/blog/cassandra-error-handling-done-right >>>> >>>> However, when I tested the process, >>>> the subsequent read can get the previous data which should be >>>> overwritten. >>>> >>>> Is the repair not always executed in the read? >>>> >>>> Thanks, >>>> Yuji >>>> >>> >> >
