> However, I am missing a piece. I need the ability add an item to the > cache > but not to broadcast that event to the other lateral caches. We need the > ability to distinguish between an init or local update and an actual > change > to the item in cache.
This is already done. Otherwise the system would get into an escalating loop. You can also configure a region and even an element to stay local or to not be a candidate for an auxiliary cache. > My thought was to extend the put method(s) in cache access to pass in a >flag that would indicate that the update is local. Does that seem >reasonable? Thoughts? This should be handled in the element wrapper instead of multiplying parameter and methods. It probably already is. The general pattern should be that most everything you need to know about an element is indicated in its wrapper. I thought Auxiliaries use the CacheManager and not the CacheAccess classes. Auxiliaries are not clients or users of the cache; they are plugins. No method is needed. Cheers, Aaron > -----Original Message----- > From: Todd Carmichael [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 01, 2003 1:48 PM > To: 'Turbine JCS Developers List' > Subject: [lateral cache] RemoveOnPutMode and localUpdate > > JCS developers, > I am working on adding RemoveOnPutMode functionality within the JCS > framework. Our team is building a web application that uses turbine, > torque > and jcs. I have been looking on how to extend the jcs TCP auxilary > lateral > cache to enable RemoveOnPut. I have made changes to LateralCache.java, > LateralCacheAttributes.java, and LateralCacheManager.java so that if the > cache is configured with the property: > > > jcs.auxiliary.LTCP.attributes.RemoveOnPutMode=true > > > Then the LateralCache will issue a remove instead of an update. This is > working mostly fine. I have also configured the lateral cache to use > PutOnlyMode to true. In this way, we only invalidate other caches if the > object changes on the lateral cache on a particular server. I will > provide > these changes as a patch when I have completed testing. > > However, I am missing a piece. I need the ability add an item to the > cache > but not to broadcast that event to the other lateral caches. We need the > ability to distinguish between an init or local update and an actual > change > to the item in cache. This would prevent a storm of network messages that > would result as each server is loading up their cache items and > invalidating > the other lateral caches. If I am extending the idea of the lateral cache > beyond what is intended, I would appreciate someone filling in the gaps in > view of the design of the lateral and remote caches. Going on the > assumption that I would to perform a localUpdate on the cache, I do see > that > the CompositeCache.java class has the notion of a localUpdate method and > that would do the trick. However, the CacheAccess.java class, which is > the > layer to be used by jcs clients, does not expose the localUpdate > capability > in any methods. The only thing CacheAccess provides is a simple put. My > thought was to extend the put method(s) in cache access to pass in a flag > that would indicate that the update is local. Does that seem reasonable? > Thoughts? > > Then lastly in torque I would change the AbstractBaseManager.java to call > the update with the flag set if it has already found the item in its > cache. > > Thanks, > Todd Carmichael --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
