[Hawkular-dev] approach for managing consistency with Cassandra

Joel Takvorian jtakvori at redhat.com
Tue Dec 20 04:46:22 EST 2016


Regardless the underlying mechanisms, there's still a logical distinction
between updates and inserts, and here the proposed algorithms seem
relevant, if I understand, only for inserted rows: step 4 of reading says "The
client code culls rows where the transactionUUID existed in the
IncompleteTransactions table." which means, applied to the Inventory case,
that it will not return any Entity that is currently modified in an ongoing
transaction. Which would not be the desired behaviour for us, we'd like to
have the pre-transaction state.

It's explicitly written in the post, quoting:
"This is just an example, one that is reasonably performant for
ledger-style *non-updated inserts*. For *transactions involving updates* to
possibly existing data, more effort is required, generally the client needs
to be smart enough to merge updates based on a timestamp, with a periodic
batch job that cleans out obsolete inserts."

Or is there something I haven't understood here?


On Mon, Dec 19, 2016 at 3:24 PM, John Sanda <jsanda at redhat.com> wrote:

>
> On Dec 19, 2016, at 3:09 AM, Joel Takvorian <jtakvori at redhat.com> wrote:
>
> Thanks John, very interesting reading.
>
> No luck for us in inventory, as there's essentially updates rather than
> inserts, which is a bit more complicated than the solution described: "generally
> the client needs to be smart enough to merge updates based on a timestamp,
> with a periodic batch job that cleans out obsolete inserts”
>
>
> Can you explain more what you mean about there being updates rather than
> inserts? Inserts and updates are the same in Cassandra. Think of a put
> operation on a map.
>
>
> But now we're considering the alternative of reading/writing the whole
> graph at once and process queries in memory. If "the whole graph" is too
> big to fit in memory without problems, then we should find a way to
> partition it.
>
>
> On Sat, Dec 17, 2016 at 2:54 AM, John Sanda <jsanda at redhat.com> wrote:
>
>> This thread post https://goo.gl/8cpSwM from cassandra-users list has a
>> good write up on an approach for implementing transactions across multiple
>> tables in order to provide stronger consistency. I found it particularly
>> interesting in light of the discussions of inventory and consistency.
>>
>> - John
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20161220/6e55f190/attachment.html 


More information about the hawkular-dev mailing list