I had a look at https://jira.jboss.org/browse/JBCACHE-1582
and wanted to share some
thoughts with you.
On one side, the recycle queue does not seem to be working when
DefaultEvictionActionPolicy.evict throws an exception. This is because the return is never
used by its client.
On the other side, the more difficult problem is what to do with expiration algorithm in
the scenario explained. I looked at the option of registering eviction events for
puts/removes/clear commands at prepare time if there's a transaction going on
(currently, the event would be registered regardless during the put/remove/clear calls).
By doing this, once the prepare call executes, cache.peek() in
ExpirationAlgorithm.getExpiration() can see the node assuming that eviction thread runs
after commit has done its job. The reason for all this is cos in expiration algorithm,
there's not a recycle queue and you cannot know whether a key you're trying to
expire might exist cos its in another thread's invocation context.
I've quickly run this change in the testsuite and OL eviction does not seem to like it
due to its implicit transactions which do not seem to call prepare, they commit directly
and commit calls come without modifications.
Thoughts? Wondering whether you'd have any other possibilities in mind for solving the
expiration algorithm issue.
Sr. Software Engineer
Infinispan, JBoss Cache