commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mainguy, Mike" <MMain...@kmart.com>
Subject RE: [cache] Turning cache into a thin abstraction layer a la logg ing ?
Date Tue, 02 Dec 2003 17:13:03 GMT
On this subject, most of the material I see on this topic deals with
retrieving and storing info that is expensive to get somewhere else.  Most
of the solutions, however, also assume that it is acceptable that the object
be removed from cache for whatever reason (time expired, memory low,
whatever).  It seems, however, that it is assumed the developer will code in
a defensive manner such that, if the object has been removed from cache,
they will recreate the object and put it back in there.  Is this the way
commons-cache is supposed to work?

I personally would rather have a caching mechanism that is transparent and I
can have the objects be managed more hands off with a simple interface that
tells the cache manager how to refresh the data on them.  In my vision, I
would create an instance of an object and I would add it to the cache
manager.  After that, I would retrieve the object from the cache manager and
it I will automatically get a copy that was refreshed at the proper
interval.  (e.g. every 15 minutes).


worse is better 

-----Original Message-----
From: Emmanuel Bourg [mailto:e.bourg@cross-systems.com] 
Sent: Tuesday, December 02, 2003 9:24 AM
To: commons-dev@jakarta.apache.org
Subject: [cache] Turning cache into a thin abstraction layer a la logging ?


It seems the cache component in the sandbox is no longer developed, 
however I'm convinced there is a need for a common caching API, at least 
until the JSR 107 is completed. I think the cache component could be 
turned into a thin layer similar to commons logging, abstracting the 
various implementations already available (JCS, OSCache, SwarmCache...).

The JCache project uses this approach (http://jcache.sourceforge.net), 
it tries to implement the first published specifications of the JSR 107, 
but it seems the final specification will be completely different and 
Map based.

For the API I was thinking at :
- a Cache interface extending the java.util.Map interface and adding a 
CacheException on the put, get, remove and clear methods.
- the CacheException would be a runtime exception so that a cache can be 
used as a Map without additional try catch blocks
- an abstract CacheFactory with a static getCache(String region) method 
(and maybe a similar getCache(Class cls) method)
- Cache and Factory implementations for some open source caches (at 
least JCS)
- a simple cache implementation, wrapping the LRUMap from commons 
collections for example
- the component will not be responsible for the configuration of the cache

I'm willing to contribute if it is seen as a step in the right direction.

Emmanuel Bourg


-----------------------------------------
This message and its contents (to include attachments) are the property of Kmart Corporation
(Kmart) and may contain confidential and proprietary information. You are hereby notified
that any disclosure, copying, or distribution of this message, or the taking of any action
based on information contained herein is strictly prohibited. Unauthorized use of information
contained herein may subject you to civil and criminal prosecution and penalties. If you are
not the intended recipient, you should delete this message immediately.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message