[Jpolycache-users] FW: working version of an attribute driven cache

[Aaron S. <aar...@ve...>]

-----Original Message-----
From: Aaron Smuts [mailto:AS...@th...]
Sent: Friday, June 08, 2001 4:01 PM
To: tur...@ja...
Cc: jak...@ja...
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


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:jam...@ma...]
Sent: Wednesday, June 06, 2001 12:53 PM
To: tur...@ja...
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:AS...@th...]
Sent: 06 June 2001 17:06
To: tur...@ja...
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


---------------------------------------------------------------------
To unsubscribe, e-mail: tur...@ja...
For additional commands, e-mail: tur...@ja...