3:46 a.m.
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(a)redhat.com> wrote:
On Dec 19, 2016, at 3:09 AM, Joel Takvorian <jtakvori(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev