The cache I sent is a variation on the ocs4j cache that avoids the network clutter of primary lateral caches, the slowness of handling the difference between put and update, the cumbersomeness of coding around exceptions being thrown to signify expected situation ( eg. failed gets ). I started to implement the entire interface but found the overhead of the api tremendous. I never create a cache loader. It seemed unnecessary. About the memory maintenance algorithm. A simple lru implemented with a double linked list is most efficient and serves almost every need. Of course the memory cache should be pluggable. Each cache keeps tracks of local (ram hits, raf hits) and auxiliary hits (remote hits), misses, ram size, etc. We built into a production version a non element attribute version is in production while I finish this one ) a jetty server that will give remote cache stats, there is also a method of the cacheServiceAdmin interface that returns stats. > I think we're pretty much aiming at the same thing. I just want to keep the > public API nice and simple so it can be used anywhere (application, applet, > servlet, EJB) and has low dependency and can be either really simple (e.g. > just one LRUMap instance) or quite complex (using notification & messaging > systems, JMX, J2EE et al) with possibly hierarchial dependency tracking and > all sorts of other gizmos. It's fully configurable on a per region basis and then by element give the regional limitations. Later it will have a service framework. I described this briefly on the turbine-dev list. Take a look. Right now it is not pluggable. No major changes need to take place to make it so. It is pretty much interface driven, so substituting in a new package should be easy. The remote client will have to be moved out of the hub. We sacrificed a flexible pluggable structure for a fast configurable one. I now think we can have both give the general composite pattern followed. I'll get something like log4j up soon. http://www.psoft.net/~asmuts/ Oh, I used an old version of the cache, more simplified to manage Inside.com's content management system. We didn't have much hardware, so I replaced Vignette's junky storyserver caching with it and got much better performance. Now, at a real estate property management asp, I'm using a version that is regionally driven ( not elementally ) in a production environment with 10 web servers, 4 app servers, and 4 script servers, all of which are participating in some manor. We have full session failover across 10 machines. We could operate without a sticky loadbalancing and still function ( poorly ). ( The session folder in the zip is not what we are using. I converted the session stuff into the group cache and didn't make the session wrapper use the group cache yet. ) Remote cache hot standby support comes next. Aaron Re: [PROPOSAL] Cache project... ---------------------------------------------------------------------------- ---- From: James Strachan Subject: Re: [PROPOSAL] Cache project... Date: Fri, 18 May 2001 05:39:50 -0700 ---------------------------------------------------------------------------- ---- Hi Daniel From: "Daniel Hoppe" <[EMAIL PROTECTED]> > I did not follow the ObjectPool discussions to closely, so I hope I'm not > missing the point. I didn't really follow the ObjectPool discussion either. > As far as I got it > > - the pool hands out an object exactly once. The object is unavailable for > others until it is returned > - the cache may hand out an object several times. The object is not > exclusively used. Thats my understanding too. In caching the same (read only) object is returned to all callers, rather than removing it per caller and putting it back again when they've finished with it. The two are quite similar from an implementation perspective but semantically quite different. There could be some potential sharing of common interfaces or implementation code across the two. > James, what do you think of making a cache JMX compliant? Sounds a great idea - particularly as the JMX compiance part could be a configurable, optional extra. I like the idea of being able to manage the cache & see whats being cached, per region, in different JVMs. I've never looked at JMX yet though. > I'm working on a > cache which is supposed to buffer data in a content management system. The > cache is supposed to store objects which are quite expensive, the caching > will be crucial for application performance. I've pretty similar needs & goals. Caching of expensive objects. (e.g. XML / XSLT documents for example). > That's why I need to have a > good overview on what's happening inside the cache, not just as some > debugging output but rather in a fashion that can be remote monitored and > integrated with monitoring tools. Agreed. > I plan to implement the measures > - objects in cache, > - cache hits, > - invalidations, > - cache misses of key that have not been in the cache yet, > - cache misses due to a constraint of maximum cache entries. > > The last two points might seem a little bit strange at the first thought, > but I think they can make a sense in certain situations. If a cache has the > option of either using soft references or a maximum number of entries, there > will be a certain amount of cache misses due to either a limited heap size > in case of soft references or a limited number of maximum entries allowed > (which is most probably related to heap size as well. Agreed. I'd like these kind of caching strategies and policies to be configurable at deployment, on a per region basis. Kinda like log4j has category based logging configuration, I'd like the same for caching. FWIW theres a SoftRefHashMap in the collections project too that might be useful. > With this monitoring information a sysadmin could easily determine if e.g. > an installation would benefit from an increased heap size. Agreed. > To distinguish between both types of cache misses it is of course necessary > - to keep a list of keys which are already known to the cache > - to have a mechanisim to finally drop keys after a certain while (e.g. the > key of a deleted page in a content management system should not remain in > the cache for weeks and months). > > This implies that the value object needs to have noticeably higher amount of > heap consumption and computation time on creation than the key, otherwise > the cache would of course not make much of a sense. > > In my current prototype I'm supplying three types of caches, a cache which, > when full, > > - drops the oldest value objects, > - drops the ones with the longest interim since the last hit > - drops the ones with the fewest number of total hits > > I can configure which kind of references are used (strong, soft, weak). > > I like the idea of a cacheloader. Thought of that as well, but somehow did > not have the drive to implement that in my ejb environment yet (might be > messy if the cacheloader has to deal with FinderExceptions of EJBs). I like the idea of the CacheLoader interface throwing exceptions, so it doesn't need to catch them then a cache region can decide what to do about it. (e.g. take down the cache, alert the JMX agent or whatever). > What I did not fully get so far is the idea of the cache-regions. I always > thought of putting a cache instance to some central location (Web > Application Context, JNDI Tree, e.g.), but maybe my view is to J2EE focused > on this. I'm a little bit sceptical about a cache being a static member as > there are some restrictions on that in the EJB spec.. Agreed. You can always use that lovely "transient" keyword ;-) A CacheRegion could be initialised & stored in a Web Application Context or JNDI tree if you like. The main idea behind the 'region' was to (a) avoid lookups to find it when it makes sense to do so and (b) allow per-region based configuration. Rather like log4j's categories, you might want to have different regions for different Java packages, or semantic names and so on. > Altold, do you think we are trying to achieve something similar or is my > approach too much heavy-wheight for your needs? I think we're pretty much aiming at the same thing. I just want to keep the public API nice and simple so it can be used anywhere (application, applet, servlet, EJB) and has low dependency and can be either really simple (e.g. just one LRUMap instance) or quite complex (using notification & messaging systems, JMX, J2EE et al) with possibly hierarchial dependency tracking and all sorts of other gizmos. James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---------------------------------------------------------------------------- ----
