Conflict Manager and Partition Handling Blog
by Ryan Emerson
Hi Everyone,
Here's a blog post on the introduction of ConflictManager and the recent changes to partition handling.
http://blog.infinispan.org/2017/07/conflict-management-and-partition.html
Cheers
Ryan
6 years, 10 months
- 4
- 10
Re: [infinispan-dev] not sure if this is the place to post a question on infinispan
by Wayne Wang
Hi All,
I am not sure if this is the place I could post a question on infinispan.
Basically, I am testing a scenario of invalidation cache in a cluster environment. It looks like the instance that actually modified the object has not problem of re-building the cache after data is updated, but the instances (in the same cluster) receiving the signal to invalidate the cache will indeed invalidate the cache, but can not re-build the cache until cache expiration.
Is this intended design, or there is some wrong in the configuration?
Thanks,
Wayne
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org [mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Sanne Grinovero
Sent: Monday, July 31, 2017 12:04 PM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Conflict Manager and Partition Handling Blog
Great job! I love to see this improved and being described in detail.
+1 to add some practical examples, as I'm afraid we only notice
limitations in features like this when thinking about specific use-cases.
The option `REMOVE_ALL` seems sensible for the disposable Cache use case. One question though: if one partition has a defined value for a key, while the other partition has no value (null) for this same key, is it considered a conflict?
I think you need to clarify if a "null" in a subset of partitions causes the conflict merge to be triggered or not. I think it should:
for example having the cache use case in mind, an explicit invalidation needs to be propagated safely.
Thanks,
Sanne
On 26 July 2017 at 13:41, Ryan Emerson <remerson(a)redhat.com> wrote:
> Hi Galder,
>
> Thanks for the feedback.
>
> Conflicts are detected by applying a predicate to the returned
> Map<Address, CacheEntry> for each cache entry. Currently this
> predicate utilises Stream::distinct (so .equals), to check for
> multiple versions of an entry. So implementing pluggable strategies
> for defining a conflict should be trivial :)
>
> Good idea about a simple tutorial/demo, I'll look into it when I get a chance.
>
> Cheers
> Ryan
>
> ----- Original Message -----
>> Oh, if we can't find a simple tutorial for it, there's always
>> https://github.com/infinispan-demos :)
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>> > On 25 Jul 2017, at 17:11, Galder Zamarreño <galder(a)redhat.com> wrote:
>> >
>> > One more thing: have you thought how we could have a simple
>> > tutorial on this feature?
>> >
>> > It'd be great to find a simple, reduced, example to show it off :)
>> >
>> > Cheers,
>> > --
>> > Galder Zamarreño
>> > Infinispan, Red Hat
>> >
>> >> On 25 Jul 2017, at 16:54, Galder Zamarreño <galder(a)redhat.com> wrote:
>> >>
>> >> Hey Ryan,
>> >>
>> >> Very detailed blog post! Great work on both the post and the
>> >> feature! :D
>> >>
>> >> While reading, the following question came to my mind: how does
>> >> Infinispan determine there's a conflict? Does it rely on .equals() based equality?
>> >>
>> >> A follow up would be: whether in the future this could be pluggable, e.g.
>> >> when comparing a version field is enough to realise there's a conflict.
>> >> As opposed of relying in .equals(), if that's what's being used
>> >> inside :)
>> >>
>> >> Cheers,
>> >> --
>> >> Galder Zamarreño
>> >> Infinispan, Red Hat
>> >>
>> >>> On 17 Jul 2017, at 14:16, Ryan Emerson <remerson(a)redhat.com> wrote:
>> >>>
>> >>> Hi Everyone,
>> >>>
>> >>> Here's a blog post on the introduction of ConflictManager and the
>> >>> recent changes to partition handling.
>> >>>
>> >>> http://blog.infinispan.org/2017/07/conflict-management-and-partit
>> >>> ion.html
>> >>>
>> >>> Cheers
>> >>> Ryan
>> >>> _______________________________________________
>> >>> infinispan-dev mailing list
>> >>> infinispan-dev(a)lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>
>> >
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6 years, 10 months
- 2
- 1