[
https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048119#comment-14048119
]
Peter Bailis commented on CASSANDRA-7056:
-----------------------------------------
bq. I doubt this will be dramatically more complex, but the approach to
implementation is fundamentally different. It seems to me supporting
transactions of arbitrary size is an equally powerful win to consistent
transactions.
I agree "streaming" batches could be really useful. In effect, you're turning
an operation you'd have to perform client-side (e.g., you can simulate
"streaming" by simply buffering your write sets and then calling one big BATCH)
into a server-assisted one (where your proposed read-buffer/memtable stores the
pending inserts while you're still deciding what goes into the transaction).
From the RAMP perspective, this doesn't change things substantially -- you just
have to make sure to propagate the appropriate txn metadata after you've
determined what writes made it into the batch.
[~benedict]: towards your point on non-QUORUM but QUORUM reads, I agree there
are some cool tricks to play. There's some additional complexity in these
optimizations, but, the basic observation is a good one: if I already have a
transaction ID I want to read from and the metadata associated with it, all I
have to do is find the matching versions which don't necessarily require QUORUM
reads for "consistency" w.r.t. the ID.
> 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)
