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 <gal...@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 > >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev