[infinispan-dev] Partial updates in 2LC

Galder Zamarreno galder at redhat.com
Fri Dec 14 04:08:49 EST 2018


Forgot to point out, here is where Sync logs the exception:
https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java#L78

On Fri, Dec 14, 2018 at 10:05 AM Galder Zamarreno <galder at redhat.com> wrote:

> Hey Radim,
>
> We've had some chats in the past where we discussed the behaviour of
> non-tx 2LC and partial updates. I've wrote a couple of tests [1] to see how
> things behave:
>
> For a repl read-write, entity cache, if the failure happens on the async
> FutureUpdate call, that's fine because the Tombstone has already been sent
> and the cache won't return anything.
>
> If the failure happens when the Tombstone is sent, we seem to have a
> problem because it results in stale data in the node that failed to apply
> the Tombstone. The FutureUpdate that comes after the Tombstone cannot apply
> because it doesn't find the Tombstone.
>
> Sync logs any errors but does not propagate them [2]. Is there any reason
> for not rethrowing the exception? I tried to rethrow it and the JDBC
> transaction rolls back, which is not too bad cos at least that way both
> nodes contain the last committed data.
>
> As a side note, the CorrectnessTestCase subclasses are not running by
> default, we should change that.
>
> Cheers,
> Galder
>
> [1]
> https://github.com/galderz/infinispan/commit/2934e0b3e8ab9af5fb1471c5fdbb0716e5a11c31
> [2]
> https://github.com/infinispan/infinispan/blob/master/hibernate/cache-v53/src/main/java/org/infinispan/hibernate/cache/v53/impl/Sync.java
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181214/e70b5dbd/attachment.html 


More information about the infinispan-dev mailing list