[infinispan-dev] EvictionListener.preEvict() vs postEvict()

[Manik Surtani]

On 19 Oct 2010, at 15:13, 이희승 (Trustin Lee) wrote:

> Is there a reason why we have two listener methods for eviction?  Can we
> affect the behavior of the eviction if we do something in preEvict()?
> To me, it seems like we cannot and I failed to see what benefits there
> are to have the two listener methods.

The reasons are historic (legacy JBoss Cache stuff).  And also to keep in line with most other notification events, which have a pre and post notification.

> Also, preEvict() has no value parameter, but the value of the
> to-be-evicted entry seems to be always known when preEvict() is called.
> Is there a reason why preEvict() doesn't have the value parameter?

That is probably something Vladimir can answer, but looking at the code I don't see why it cannot have a value as well.  All of the containers calling preEvict() already has a hold of the entry (which is how it gets a hold of the key).  So passing in a value to preEvict() shouldn't be a problem.

> I also wonder modifying the EvictionListener interface will affect the
> users breaking the backward compatibility with 4.1.  I merely thought it
> will break the backward compatibility because it's a public interface,
> but I realized that it might not be the case while I'm investigating
> ISPN-703, which also makes changes in the public interface.

EvictionListener is an internal interface.  I don't see any public use of this interface so it should be safe.

However, ISPN-703 will alter the Event interfaces passed to cache listeners annotated with @Listener, by adding a getValue() method.  I don't again see this as a problem since it adds a method, rather than removing or altering existing methods.  And again, the Event interfaces aren't public extension points so it shouldn't really break anything.

Cheers
Manik
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org