> I actually like the way Turbine's CacheService deals with > this: objects > that are refreshable implement an interface which defines one argument > 'refresh'. When an element is expired the cache looks to see if the > object implements that interface and if so, calls the refresh > method. If > the method returns true the object is re-cached and returned, if false > it is expired normally.
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? Scott > -----Original Message----- > From: James Taylor [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 29, 2002 8:51 PM > To: Turbine JCS Users List > Subject: RE: How do you retrieve a collection keys for a cache region > > > I actually like the way Turbine's CacheService deals with > this: objects > that are refreshable implement an interface which defines one argument > 'refresh'. When an element is expired the cache looks to see if the > object implements that interface and if so, calls the refresh > method. If > the method returns true the object is re-cached and returned, if false > it is expired normally. > > In JCS, this is an area where I think another 'CacheAccess' would be > great -- a RefreshingCacheAccess that implements the > additional refresh > capability. > > On Mon, 2002-04-29 at 18:16, Aaron Smuts wrote: > > You have a very tricky situation on your hands. > > > > Is there anyway that you can get in between the legacy app > that updates that > > data and the database. If so, then you may need a hole > punched in the > > firewall. > > > > You can try the group function to maintain you list of > keys, but this will > > reduce the efficiency of the cache inserts. > > > > One feature I'm thinking about would be a cacheLoader. You > could associate > > an element with a loader and if it expired the loader would > re-fetch the > > data. This would solve your problem. There would be a > simple interface for > > a loader and an element can have a loader attached. > > > > Another option would be to register a listener with an > element that the > > cache could actively call. This too would be a new > feature, but it is a bit > > simpler. The listener would be notified that the element > expired (you can > > use the auto-shrinking of the memory cache to expire the > data), and you > > could do whatever you wanted in the listener. > > > > All we need to do is add listener interface and a variable > to the element > > attributes for it. I'm not sure listeners would serialize > well to other > > jvms. They may be strictly local. We could add something > like a class > > name to instantiate and a method to call on destruction to > the element > > attributes class. This would be easy. > > > > Aaron > > > > > > > > > -----Original Message----- > > > From: Weaver, Scott [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, April 29, 2002 5:37 PM > > > To: 'Turbine JCS Users List' > > > Subject: RE: How do you retrieve a collection keys for a > cache region > > > > > > > You can associate elements by putting a ":" into the key. > > > > > > I am currently using this naming technique. > > > > > > > Let me know what you are trying to do. I may have a > better idea. > > > > > > I am currently running in a single jvm, so that alleviates some > > > complexity, > > > I think. > > > > > > Here is my scenario. I have a legacy system (a separate > AS/400 sitting on > > > the other side of DMZ from my appserver). My webapp > accesses both price > > > and > > > availability on the AS400 using OJB then and then stores > results into JCS > > > to > > > increase performance for subsequent requests. This is > working great. > > > However, since pricing and availability can be changed by > the legacy app, > > > i > > > need to update that information (price and availability) > on regular basis, > > > 15 minutes and one hour respectively. > > > > > > Access to both price and availability are provided by a > set of fulcrum > > > services. These service implement an interface, > IRefreshableCache , that > > > contains a method called refreshCache(). On initialization, these > > > services > > > add themselves along with a refresh interval to a third, > management > > > service > > > that implements the IRefreshableCacheManager interface. > > > IRefreshableCacheManager runs an instance of an internal > class, Refresher, > > > in a separate MIN_PRIORITY, daemon thread which runs > every 10 seconds and > > > checks to see if any if the refresh intervals for the > IRefreshableCache > > > objects managed by the IRefreshableCacheManager have been > met or exceeded. > > > If the interval has been met or exceeded the > refreshCache() of the > > > IRefreshableCache object is called. > > > > > > Here is were I need the list keys so I can grab each > cached object, re- > > > query > > > the AS400 using OJB, and replace the stale cache value > with the fresh one. > > > My current work around is that I maintain an ArrayList > that keeps track of > > > cache keys, but I would prefer to scrap that and directly > access the keys > > > from the cache region. > > > > > > I don't want to expire the objects as that will require > user requests to > > > re-query the database which be lengthy for some items. > > > > > > > > > very long...sorry > > > > > > scott > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Aaron Smuts [mailto:[EMAIL PROTECTED]] > > > > Sent: Monday, April 29, 2002 4:46 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: re: How do you retrieve a collection keys for > a cache region > > > > > > > > > > > > * From: Weaver, Scott > > > > * Subject: How do you retrieve a collection keys for a > > > > cache region > > > > * Date: Thu, 18 Apr 2002 12:12:45 -0700 > > > > _____ > > > > > > > > Is there anyway to retrieve a collection of all of the keys > > > > for a paticular > > > > cache region? > > > > > > > > Thanks, > > > > Scott > > > > > > > > > > > > > > > > Hi: > > > > > > > > One way to manage a list is to use the group feature. You > > > > can put elements > > > > in a group that is within a region. The list of elements > > > > within a group is > > > > managed across servers. The list isn't transmitted, but > > > > updates to the list > > > > are. So, all of the elements do not have to be present for > > > > you to know > > > > about them. > > > > > > > > I'm not sure why you need the list, but generally it isn't > > > > necessary. Often > > > > it is better just to put a list into one element. > > > > > > > > If you need to delete related elements, one good way to do > > > > this is to use > > > > the hierarchical delete mechanism. > > > > > > > > You can associate elements by putting a ":" into the key. > > > > You can call > > > > remove with a partial key ending in a ":" and all the > > > > elements starting with > > > > that key will be removed. > > > > > > > > If we allowed direct access to the cache manager, or the hub, > > > > then you could > > > > get a list of all the elements in memory or on disk. > > > > Depending on your > > > > distribution settings and your environment, this might not be > > > > a complete > > > > list of all the elements that are in the region in all the jvms. > > > > > > > > Let me know what you are trying to do. I may have a > better idea. > > > > > > > > Aaron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Aaron Smuts > > > > Director, Systems and Development > > > > e-Business Division > > > > REALMCash > > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > > > office: (212) 653-0578 > > > > cell: (646) 263-5398 > > > > > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
