9:13 a.m.
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.
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?
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.
Thanks in advance,
Trustin
--
Trustin Lee - http://gleamynode.net/
3:16 a.m.
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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
4962
days inactive
4963
days old
infinispan-dev@lists.jboss.org
1 comments
2 participants
participants (2)
-
"이희승 (Trustin Lee)" -
Manik Surtani