2010/8/12 Manik Surtani <manik(a)jboss.org>:
Guys,
A problem with eviction, passivation and the new data container has been reported in
ISPN-582. A quick summary, eviction now takes place within the data container as
containers are naturally bounded. This means once a size threshold is reached entries are
automatically removed. More accurately, they are just stored in a separate collection and
the eviction thread picks them off this collection and calls evict() on each one. Now we
have some issues here:
1) This means notifications are often dispatched later than when the actual eviction
takes place. No biggie though, eviction is best-effort.
2) Passivation too is delayed. This is huge. This means there is a window where a
thread may ask for an entry but the entry is in limbo - not in the data container, not yet
passivated to a cache store.
I am currently testing a fix for this, where the data container handles notification +
passivation (if enabled) directly, when an entry is evicted from the primary data
collection. So far this seems to work, however this all happens on the caller's
thread now. So in a sense, I wonder if the EvictionThreadPolicy is relevant.
However, my fix is only a temporary one - since it still doesn't work when using
LIRS, as LIRS maintains 2 separate stacks and only the LIR stack is queried on a get and
not the HIR stack. So for now we should consider LIRS + Passivation as an invalid
configuration.
https://jira.jboss.org/browse/ISPN-598
Anyway the key thing is, it all works fine now, so lets open this discussion again when
Vladimir is back from vacation.
thanks for the nice explanation, very valuable.
Did you consider that the "limbo" area could be promoted to be a valid
place to look for entities when they are not found in the main
container, and before trying a load from a store?
Basically you would have your container split in two areas, something
like JVM heap areas; I guess that would be quite a change.
Sanne