cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7056) Add RAMP transactions
Date Mon, 15 Sep 2014 13:31:34 GMT


T Jake Luciani commented on CASSANDRA-7056:

I've been thinking about how to implement this and a couple ideas come to mind:

  * We would use the existing batchlog and use this as the prepare pass of the transaction
  * Since we will use TimeUUID as the timestamp we can also use this for the batchlog id
  * We add a way to find and read from the batchlog for a given batchlog id.
  * If the coordinator gets the results from two partitions and the timeuuids don't match
it would read the later timeuuid from the batchlog and fix the data.

Some concerns:

  * Let's assume we query from partition A and B, and we see the results don't match timestamps,
we would pull the latest batchlog assuming they are from the same batch but let's say they
in fact are not.  In this case we wasted a lot of time so my question is should we only do
this in the user supplies a new CL type? I think Peter was suggesting this in his preso READ_ATOMIC.

 * In the case of a global index we plan on reading the data *after* reading the index. The
data query might reveal the indexed value is stale. We would need to apply the batchlog and
fix the index, would we then restart the entire query? or maybe overquery assuming some index
values will be stale?  Either way this query looks different than the above scenario.

> Add RAMP transactions
> ---------------------
>                 Key: CASSANDRA-7056
>                 URL:
>             Project: Cassandra
>          Issue Type: Wish
>          Components: Core
>            Reporter: Tupshin Harper
>            Priority: Minor
> We should take a look at [RAMP|]
transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like)

This message was sent by Atlassian JIRA

View raw message