[
https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043851#comment-14043851
]
Peter Bailis commented on CASSANDRA-7056:
-----------------------------------------
[~jjordan] Good question. The short answer is that this behavior (reading A @2
and C@1) is well-defined under RAMP. Just like in Cassandra today, the fact
that I read a write at time 500 doesn't mean I'm going to see the effects of
all writes that occur before time 500! Rather, the guarantee that RAMP adds is
that, once you see the effects of one write in the the batch, you'll see all of
the writes in the batch.
So, in your scenario, you have three batches: B1 {A=1, B=1} at time 1, B1.5
{B=1.5, C=1.5} at time 1.5, and B2 {A=2, B=2} at time 2. You could get the
behavior you describe above if B1 executes and completes, B2 executes and
complete, and we subsequently read sometime before B1.5 completes. So, I guess
I disagree that "the real C you should be getting is the one from [the batch at
time 1.5]" because you didn't yet see the effect of any writes from B1.5.
However, once B1.5 completes, you *will* be guaranteed to read C at time 1.5.
It may be easier to think of RAMP as providing the ability to take each of your
normal reads and writes under LWW and turn them into multi-column, multi-table
writes that are all going to be visible/reflected in the table state (once
completed). There's no special ordering guarantees beyond what Cassandra
already provides; if you need strong ordering guarantees (e.g., enforcing
sequential assignment of timestamps), it's a case for CAS.
> 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.2#6252)
