>Aaron, >Have you talked to the guys in the commons project about the stuff they are >doing on caching? >James Not really. They were talking about a cache project in the commons and there was interest in the turbine group, so I'll send this to both places. Sorry about the spam, but the topic overlaps. I updated the zip and added some java-docs with uml. http://www.psoft.net/~asmuts/ Since a few people emailed me directly, I'll give a rough overview of the caching system. Very briefly: Right now the cache has 4 parts that can become plugable services: memory, disk, lateral, and remote [which has any combination of the others]. I'm going to make the central cache class into a hub with plugable services -- one-way and two-way stores: some for distribution and others for searching. I'd like to make a log4j like framework. The cache is divided into regions and supports in-region groups that provide the ability to associate and list grouped elements ( most useful for sessions ). Each cache element can be configured to expire, spool to disk, laterally distribute, and remotely synchronize with other caches if the overall regional attributes allow these behaviors. Elements are stored in memory in a double-linked list and spooled to disk using a simple lru algorithm. When objects are put in the cache they are laterally distributed if this option is on. The lateral cache is not intended for heavy use. It exists mainly for direct removal. Keeping items in synch and available when needed is up to the remote cache. The remote cache is updated with up-to-date copies of items in the local caches. Local caches can be configured to get items in a failure sequence. Generally a local cache will check memory then disk and then the remote cache before returning null. If an item is found remotely it is move to the local cache's memory cache. Local caches register themselves with the remote cache and when an element is put to the remote store, the remote servers notifies all listening local caches that the particular key is invalid. This avoids the network overhead of transmitting data that might not be needed. Each local cache adapts to the behavior patterns of it's users and doesn't force a memory list on the others. Also, with one remote store it is easier to keep the sequence of updates and invalidations in order. Obviously there are disk write locks, remote reestablishing background threads, mirrored attribute lists, and more detailed features to talk about. I'm still cleaning it up after the conversion. If jakarta isn't interested, please let me know. I need a repository and will just put it on sourceforge so I can work on it. Aaron -----Original Message----- From: James Coltman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 06, 2001 12:53 PM To: [EMAIL PROTECTED] Subject: RE: working version of an attribute driven cache Aaron, Have you talked to the guys in the commons project about the stuff they are doing on caching? James -----Original Message----- From: Aaron Smuts [mailto:[EMAIL PROTECTED]] Sent: 06 June 2001 17:06 To: [EMAIL PROTECTED] Subject: working version of an attribute driven cache I have a working version of the cache after converting it into an element attribute driven system. It has disk spooling, disk defragmentation, remote storage and synchronization, http lateral multicasting and direct lateral deleting, cache regional specifications, global defaults, element attributes, group and region element attribute defaults, session api like group behavior . . . I had to take the system which was regionally defined and move the logic to the element attribute level. I'm still cleaning it up. It needs an ant make and the log needs to be moved to log4j. Later I can make distribution and search like appenders that can be replaced. It isn't that flexible right now, but is still composite in nature. Right now I'm working on remote cache failover and clustering. . . Where should I send it? Aaron >> It seems like this would be a useful addition to Turbine. I can describe >> what I have in mind in more detail if anyone is interested. >I don't know how I can say this clearly enough...BRING IT ON! :-) >-jon
