[
https://issues.apache.org/jira/browse/CASSANDRA-11171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147913#comment-15147913
]
stuart commented on CASSANDRA-11171:
------------------------------------
Sorry I should have elaborated a bit. I'm not by any means suggesting any form
of performance improvement over paxos. Im developing a platform running on MS
Project Orleans and so I have external means to control concurrency. (Infact
I'm using cassandras lightweight transactions to guarantee single activation of
actors). So having guarantees over actor isolation and single threaded
execution already in place I'd like to be able to perform conditional updates
for certain use cases. I do not have to worry about contention because I know
these updates will be executed in a coordinated manner. Thererfore the
atomicity of the conditional update operation currently provided by Cassandra,
should not be required and I was wondering if there could be a means to turn it
off? I'm not an expert in distributed programming so may well be missing
something in my thinking here,
Thanks,
Stuart.
> conditional update without paxos
> --------------------------------
>
> Key: CASSANDRA-11171
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11171
> Project: Cassandra
> Issue Type: Wish
> Reporter: stuart
> Priority: Minor
>
> I realise that currently conditional updates use lightweight transactions to
> provide an atomic check and set operation but that this comes at a non
> trivial performance cost. I have a solution where synchronised access is
> ensured by an external mechanism therefore I don't think paxos would be
> required. It would be nice to be able to run an update command or script that
> could conditionally update without the performance hit. Currently I'd have to
> retrieve each row first at the application level before deciding whether or
> not to perform the update. Would it be possible to add a switch for the
> conditional updates to turn paxos on or off? Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
