Re: [infinispan-dev] Passivation and BCHM WAS: fixing eviction with transactions (critical for Hibernate Search)

It looks as a good improvement, especially as we remove the locking, but I still have some doubts: 1) as the passivation happens in the eviction thread, is that going to be fast enough or hindering the eviction performance? especially with LIRS, being this the user thread it means that put operations suffer a mayor performance hit (for async caheloaders, see next point). Well this was the case already, I guess.

2) with async stores, the issue is back. The value is not going to be found while it's "in flight" in the async storage queue; so unless you want to avoid supporting it for now, the actual removal from the container should be performed from the async cache loader code.

So it looks like that - when passivation is enabled - the proper way to implement this is to use the eviction policy only to identify what's going to be removed from the container, but not to actually remove it. I'd still focus on having the best performance possible for the case in which passivation is not enabled, that looks like the "performance needing" setup, or maybe we need separate eviction strategies fro when passivation is enabled.

3) so every time we evict an entry, we write it to the store.. I guess that leads to re-write quite often values which are already in the store, and for which there's no need to store again. I think this argument came up before, but we didn't want to track an additional boolean to keep the memory need low. Still when we're using it as a cache with eviction rules in place, it seems to me that overall performance would be better by avoiding more writes at the cost of being able to store some less entries in memory.