Hi all, First of all I would like to thank you all for your prompt responses. I really appreciate and I've been considering carefully all the suggestions.
Young Wayne proposed an additional hashmap, but this is working only in a non distributed environment. When using a remote cache (as I need to) to synchronize local caches, your additional hashmap will not receive the event of entry invalidation or new elements coming from the remote cache. So you might have the case where invalidated cache entries keys are still "polluting" your additional hashmap while not existant anymore in the JCS cache, or that not all the entries are present in your additional hashmap. Furthermore, I'm not avoiding the iteration of the second hashmap. For example, if I'm using an additional hashmap for tracking the second item, as you proposed, I will have to parse the JCS keys stored in the hashmap to know it there is a key holding a first item that have to be invalidated. When this is the case I will have to remove this key from the additional hashmap either. As Aaron pointed out, and he's right, I do not want to serve a stalled page, and therefore pageIDs have priority over userIDs; it's already what I was doing with hierarchical removal (pageid+":"). But ideally I would like to do the same when a user logs off or his/her session expired; I've already implemented an automatic expiration on elements, but as Aaron suggested, I might just base the cleanup on the element expiration, and not offer the ability to force a userID cleanup. I've been looking, as Aaron suggested, for using a region for each pageid. But it's unclear for myself how these regions behave in a distributed environment: - First of all, if I'm right, regions can only be created through the CacheAccess.defineRegion(..) static methods, which return a CacheAccess instance; or directly by instanciating a CacheAccess object. Once such a region has been created, how to I associate it to the JCS cache? - I've been looking for using the CacheAccess constructor and associate the same CompositeCache to all the regions, but it's of no use, as the put() and remove() methods of the CacheAccess are redirected to the CompositeCache removal methods. Therefore, creating a region for each pageID will not give me the ability to remove userIDs simply by using remove(userID+":"), as all the element keys in the composite cache will start with pageID+":"! - Accoding to the last point, it would be necessary to have distinct composite caches for each region. This would force me to handle myself the regions and I would lose the concept of distributed cache. Or is there any way to associate regions with distinct composite caches to a JCS cache, in order to distribute the regions to the other local caches? (I don't think so). - If it's possible to assocate multiple regions with distinct composite caches to a JCS cache, will all the other local JCS caches, in the distributed environment, be updated when a new region is created (or removed or updated) in one of the local caches? Finally, the concept of multiple keys indexing, as Hanson Char suggested, would be really nice ;) Thanks for all, Fulco --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
