Yup, I also meant 'eventually consistent' when saying such
inconsistencies should be acceptable. At some point in time after
transactions have been committed and topology changes have been handled
(state transfer completed) and we have a steady state we should see a
consistent index when
On 07/31/2017 11:12 AM, Tristan Tarrant wrote:
> Shouldn't we use an appropriate conflict resolution strategy for this so
> that in case of partitions we repair the index ?
This is not about eventual consistency in case of partitions, just
eventually publishing the change in the index after the
Shouldn't we use an appropriate conflict resolution strategy for this so
that in case of partitions we repair the index ?
Tristan
On 7/31/17 10:41 AM, Gustavo Fernandes wrote:
> IMO, indexing should be eventually consistent, as this offers the best
> performance.
>
> On tx-caches, although
IMO, indexing should be eventually consistent, as this offers the best
performance.
On tx-caches, although Lucene has hooks to be enlisted in a transaction
[1], some backends (elasticsearch) don't
expose this, and Hibernate Search by design doesn't make use of it. So
currently we must deal with
On 07/28/2017 02:59 PM, Adrian Nistor wrote:
> My feeling regarding this was to accept such inconsistencies, but
> maybe I'm wrong. I've always regarded indexing as being async in
> general, even though it did behave as if being sync in some not so
> rare circumstances, which probably made
My feeling regarding this was to accept such inconsistencies, but maybe
I'm wrong. I've always regarded indexing as being async in general, even
though it did behave as if being sync in some not so rare circumstances,
which probably made people believe it is expected to be sync in general.
I'm
Hi,
while working on ISPN-7806 I am wondering how should queries work with
transactions. Right now it seems that updates to index are done during
either regular command execution (on originator [A]) or prepare command
on remote nodes [B]. Both of these cause rolled-back transactions to be
