[
https://issues.apache.org/jira/browse/CASSANDRA-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14042898#comment-14042898
]
Benedict commented on CASSANDRA-7056:
-------------------------------------
We were discussing this internally just a few days ago. I'm very keen to see
this introduced, as I think it could have tremendous potential. There has been
a side discussion about CASSANDRA-6108 and whether this would make an
implementation simpler, by virtue of providing a unique commit id that is more
robust than a server-generated timestamp, however I am of the opinion this
could be worked in later. Using the timestamp either way certainly seems the
easiest solution, it will just benefit from improved timestamps when we get
them.
One important question for me is if we maintain a separate expired-read-buffer
from the write-buffer; optimally we would clear records from the write buffer
as soon as they make it into memtables, only we them need to track values that
are overwritten in a separate read-buffer. It might be slightly easier to
simply keep them longer in the write-buffer, however this could lead to
significantly larger memory overheads, as we keep all writes twice (instead of
only those that are overwritten)
Either way, I'm currently of the opinion we should target either a very narrow
expired-read-buffer window, or one with a fixed size, so that we can keep a
tight bound on the resources dedicated to these transactions. We also need to
take care with how we safely inform a reader that their read could not be
safely serviced from this window so that they may retry, and to fail if reads
consistently fail to reach consensus.
There are some related problems as well, namely how we expose this
functionality to the user. Currently we have no concept of a "batched read" so
this might need protocol support, but that's probably a separate
discussion/problem. As far as _writes_ are concerned, I'd be inclined to simply
replace current LOGGED batches entirely.
> 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)
