This could just be a standard ability. We could add an indicator to the to the element attributes or just add it in. Any expiration would call it. It doesn't really need an extra access class.
To use this you'd have to pass in a bean, but you'd have to be careful not to serialize everything associated, like a connection pool, etc. I was thinking of using reflection so mistakes like this would be harder to make. Aaron > -----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:turbine-jcs-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:turbine-jcs-user- > [EMAIL PROTECTED]>
