> -----Original Message-----
> From: Weaver, Scott [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 08, 2002 12:40 PM
> To: 'Turbine JCS Users List'
> Subject: RE: cache event listeners, like jcache
>
> > Perhaps the expiration handling should only be called by the
> > background
> > process in the shrinker.
>
> +1 on this approach. That is like I am currently doing (with out events).
> I run a MIN_PRIORITY daemon thread that is responsible for calling the
> IRefreshable refreshMethod(). The background process of the shinker could
> fire a cached object's expiration event when it is expired. I'm not
> familiar with how the shinker works, however I believe polling objects for
> expiration would have to be done at relatively close intervals (like every
> 10 seconds) to be effective.
The polling is configurable. Just tell the memory cache to use shrinking in
the configuration. You can set the interval, etc.
It turns out that the on-request and background events really are two
separate event types and deserve their own codes. The JCache is far to
simplistic about events in this regard. JCache events are more region wide,
or look like they were intended to be used at the region, group and element
level. I've only implemented element event handling, and I named it
accordingly.
These are the events I could think of. I only started implementing 0 and 2.
This will need to be worked on, but I'm trying to keep it really simple and
out of the way.
They are defined in:
org.apache.jcs.engine.control.event.behavior.IElementEventConstants
/**
* Background expiration
*/
public final static int ELEMENT_EVENT_EXCEEDED_MAXLIFE_BACKGROUND = 0;
/**
* Expiration discovered on request
*/
public final static int ELEMENT_EVENT_EXCEEDED_MAXLIFE_ONREQUEST = 1;
/**
* Background expiration
*/
public final static int ELEMENT_EVENT_EXCEEDED_IDLETIME_BACKGROUND = 2;
/**
* Expiration discovered on request
*/
public final static int ELEMENT_EVENT_EXCEEDED_IDLETIME_ONREQUEST = 3;
/**
* Moving from memory to disk (what if no disk?)
*/
public final static int ELEMENT_EVENT_SPOOLED = 4;
/**
* Removed activley by a remove command. (Could distinguish between
local
* and remote)
*/
public final static int ELEMENT_EVENT_REMOVED = 5;
/**
* Element was requested from cache.
* Not sure we ever want to implement this.
*/
//public final static int ELEMENT_EVENT_GET = 6;
>
> > If you handle the expiration event and it happens on a get,
> > you might get
> > into a confusing situation.
> I don't like this idea as the expiration event may perform
> performance-degrading operations like DB lookups and such. IMOHO,
> expiration events (and other non-interactive events like spool to disk)
> should be fired in the background.
>
> > a synchronous call of the handle event method.
> I would think would a requirement anyway do to the fact that simultaneous
> interactive events (removal, get and put) could cause issues.
>
> Or, what may make things a little cleaner is to implement some sort of
> event
> queuing as opposed to synchronizing the handle event method. All events
> are
> queued and fired in the order they are received or make it a priority
> queue
> where interactive events always have priority over background events.
> You
> could go as far as creating IBackgroundEvent and IForegroundEvent
> interfaces
> to make prioritizing events easier and more component oriented.
Yes this could be done and probably should be.
>
>
> my $0.02,
> Scott
>
>
> > -----Original Message-----
> > From: Aaron Smuts [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, May 08, 2002 10:53 AM
> > To: Turbine JCS Users List
> > Subject: RE: cache event listeners, like jcache
> >
> >
> > There are some tricky issues regarding the cache event interface.
> >
> > For now, we will only have one event type -- expiration. In
> > the future
> > there could be many types of events -- removal, expiration,
> > spool to disk,
> > replace, get.
> >
> > The only two that seem worth registering event handlers with
> > are removal and
> > expiration.
> >
> > Items are expired in the background cleanup jobs and at request time.
> >
> > I don't want to call a handle event and have the caller block until it
> > returns.
> >
> > Should it be up to the implementer to run it in the
> > background, or should
> > the cache run it asynchronously?
> >
> > If you handle the expiration event and it happens on a get,
> > you might get
> > into a confusing situation. Let's say that your handle even
> > implementation
> > loads another item into the cache. The caller program calls
> > get, the item
> > is found to be expired and the handle event is called. The
> > event handler
> > puts another item in the cache and then the cache returns
> > null for the item.
> > This seems funny. It might be a problem if the calling
> > program also wants
> > to put a new item in the cache if it isn't there already.
> >
> > Perhaps the expiration handling should only be called by the
> > background
> > process in the shrinker. Or, the handle event method could
> > have a return
> > value. If you return something that will be returned for any
> > get request,
> > otherwise it will be ignored. This might solve the problem,
> > but it requires
> > a synchronous call of the handle event method.
> >
> > Aaron
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Aaron Smuts [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, May 01, 2002 10:35 AM
> > > To: Turbine JCS Users List
> > > Subject: cache event listeners, like jcache
> > >
> > > 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]>
> >
