The interface way sounds like the best solution. My concerns are ungrounded and using reflection in the manner I suggested might just cause headache.
The JCache defines a CacheListener that can be attached to elements. We might want to consider keeping it close to the way it is defined here so it will be easy to use JCS if you know JCACHE. The idea is not coming from JCache though. We just might want to roughly conform to their way of naming and way of adding a listener. We could add this to the element attributes. "void setListener(int event, CacheEventListener listener) SetListener registers an event listener object to be executed when the specified event occurs with relationship to the associated object. Currently the only the invalidate event being monitored is (Attributes.INVALIDATE_EVENT)." "The CacheEventListener interface defines the following methods. 1. void handleEvent(CacheEvent event) throws CacheException HandleEvent is a callback method. When a registered event happens, the cache invokes this method and passes in a CacheEvent object." "The CacheEvent class extents the java.util.EventObject class. CacheEvent represents an internal cache event. If an event happens on a cached object, the source object in CacheEvent is the cached object which relates to the event that just happened. If an event happens on a cache group, the source object in CacheEvent is the group name which relates to the event that just happened. Event id is used to identify different types of events. Applications can register a CacheEventListener to handle events. Currently, only the OBJECT_INVALIDATED event is defined. 1. int getId() getId returns the event identifier associated with the event. Currently the only event supported is CacheEvent.OBECT_INVALIDATED." This would be very simple to implement. Overridding an object in the cache will not count as invalidation. Only exceeding the idle time or the max life will could. Aaron > -----Original Message----- > From: James Taylor [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 11:08 AM > To: Turbine JCS Users List > Subject: RE: How do you retrieve a collection keys for a cache region > > On Tue, 2002-04-30 at 10:12, Aaron Smuts wrote: > > You have to think about how this refreshable object will behave when > passed > > to another machine or serialized to disk. You don't want to serialize > all > > your utilities. > > As long as the objects don't hold references to connection pools and > such it might not be such a big deal. A refresh method could just go to > the PersistenceManager singleton and say 'refresh this object'. > > > It might be easier to add a listener by name to the element attributes. > In > > the cache hub when an element is expired on request, or in the shrinking > > memory cache when an element is automatically expired, you'd have to > call > > the class. I think the classes should have to implement a common > interface, > > but the name of the implementation class should be called by reflection. > > What is the advantage of calling with reflection versus casting here? If > they implement the interface they must have the method. I must be > missing something. > > > > > > -----Original Message----- > > > From: Weaver, Scott [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, April 30, 2002 8:34 AM > > > To: 'Turbine JCS Users List' > > > Subject: RE: How do you retrieve a collection keys for a cache region > > > > > > Give me reference point to start at and I will. > > > > > > > > > Scott > > > > > > > > > > -----Original Message----- > > > > From: James Taylor [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, April 30, 2002 8:25 AM > > > > To: 'Turbine JCS Users List' > > > > Subject: RE: How do you retrieve a collection keys for a cache > region > > > > > > > > > > > > > > > > > I have used this that in the past (pre-JCS) and was happy with the > > > > > technique. Any chance this type of functionality could > > > > find it's way into > > > > > JCS? > > > > > > > > Sure thing. Of course, the fastest way to see it is if you write it > =] > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: <mailto:turbine-jcs-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:turbine-jcs-user- > [EMAIL PROTECTED]>
