[
https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128159#comment-16128159
]
Igor Zubchenok edited comment on CASSANDRA-6246 at 8/16/17 12:45 AM:
---------------------------------------------------------------------
I would like to try, but I'm not familiar with Cassandra source code. :( Isn't
it easier to implement the patch again, but without rebase from 4 year old code?
BTW, I'm looking for a solution to implement a *reference counter based on
Cassandra*.
My first reference counter implementation has been made on counter columns, but
unfortunately it had been ruined with tombstones issue - when a counter get
back to zero, I cannot delete nor compact it.
My guess was that the lightweight Cassandra transactions can do a very good job
for my task. I was so naive and now I have an issue with WriteTimeoutException
and inconsistent state.
The only workaround I came up with today is to do an exclusive lock that can be
easily made with LWT with TTL, and subsequent change of a value, but it will
have much more greater performance hit. I'm still looking for a good solution
on that with Cassandra.
Currently I'm naive again and expecting that EPaxos will help me, but seems it
will never-never be merged and released.
Dear community, do you have any idea?
P.S. Huge thanks and warm hugs to everyone who answers me!
was (Author: geagle):
I would like to try, but I'm not familiar with Cassandra source code. :( Isn't
it easier to implement the patch again, but without rebase from 4 year old code?
BTW, I'm looking for a solution to implement a *reference counter based on
Cassandra*.
My first reference counter implementation has been made on counter columns, but
unfortunately it had been ruined with tombstones issue - when a counter get
back to zero, I cannot delete nor compact it.
My guess was that the lightweight Cassandra transactions can do a very good job
for my task. I was so naive and now I have an issue with WriteTimeoutException
and inconsistent state.
The only workaround I came up with today is to do an exclusive lock that can be
easily made with LWT with TTL, and subsequent change of a value, but it will
have much more greater performance hit. I'm still looking for a good solution
on that with Cassandra.
Currently I'm naive again and expecting that EPaxos will help me, but seems it
will never-never be merged and released.
Dear community, do you have any idea?
Huge thanks to everyone who answers me.
> EPaxos
> ------
>
> Key: CASSANDRA-6246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Blake Eggleston
> Labels: messaging-service-bump-required
> Fix For: 4.x
>
>
> One reason we haven't optimized our Paxos implementation with Multi-paxos is
> that Multi-paxos requires leader election and hence, a period of
> unavailability when the leader dies.
> EPaxos is a Paxos variant that requires (1) less messages than multi-paxos,
> (2) is particularly useful across multiple datacenters, and (3) allows any
> node to act as coordinator:
> http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
> However, there is substantial additional complexity involved if we choose to
> implement it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
