The problem of annotations is that you need to modify the cached value, and the user might
not be able to do that, e.g. not their code.
Flags are fine IMO. I only have two problems with them:
1. We don't separate user vs internal flags.
2. Flags can't carry values.
In functional, I've fixed this by doing Param (flag replacement in functional) only
for user concerns, and they can carry values.
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
On 20 Dec 2016, at 17:10, Radim Vansa <rvansa(a)redhat.com>
wrote:
Perfect! This would reduce the only limitation of dist/replicated caches
in 2LC, while I am convinced that these have much better performance
(there have been some changes recently, so I have to re-run the perf tests).
So, how should that feature be exposed to users?
1) Annotating the value class with @NonEvictable or @Evictable(false)
- What if the user can't change the class definition? That would require
us to provide alternative way as well (listing classes in configuration)
- Should we set this fixed for a value class? Inheritance?
- Should we support also @NonEvictable keys?
2) Adding Flag.NON_EVICTABLE to the write
- Flags are a bit controversial, we shouldn't add more user-facing flags
- We need a Param for functional commands as well
3) Other ways?
Should we create another type of CacheEntry (-1), add a flag to
Metadata, or something else?
Radim
On 12/20/2016 03:33 PM, William Burns wrote:
> Yes, definitely!
>
> I made sure to check when I added Caffeine [1]
>
> I was thinking we could add that later if we really need the feature.
>
> - Will
>
> [1]
>
https://github.com/ben-manes/caffeine/blob/master/caffeine/src/main/java/...
>
> On Tue, Dec 20, 2016 at 4:16 AM Radim Vansa <rvansa(a)redhat.com
> <mailto:rvansa@redhat.com>> wrote:
>
> Regarding another use of Weighter in Caffeine: would it be possible to
> guarantee that an object with weight 0 (or negative one) is never
> evicted?
>
> R.
>
> On 12/19/2016 10:10 PM, William Burns wrote:
>> Check out some of the new changes to the Data Container in
> Infinispan
>> 9.0. Beta 1 [1]. Part 2 will be probably after Holiday break.
>>
>> [1]
>
http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
> <mailto:infinispan-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@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
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev