Hi Manik, 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. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache