[
https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133886#comment-14133886
]
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 (RAMP-Fast)
* 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: https://issues.apache.org/jira/browse/CASSANDRA-7056
> Project: Cassandra
> Issue Type: Wish
> Components: Core
> Reporter: Tupshin Harper
> Priority: Minor
>
> We should take a look at
> [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/]
> transactions, and figure out if they can be used to provide more efficient
> LWT (or LWT-like) operations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
