Re: [Springframework-developer] oscache

[Ben A. <ben...@ac...>]

jürgen höller [werk3AT] wrote:

>>As far as a pluggable cache system goes, I think hibernate's model works
>>    
>>
>fairly well and I would like to see something like that in Spring.
>
>The difference is that Spring does not currently have a use case for such a cache abstraction itself. This is a bit similar to our current support for scheduling and also O/R mapping: I prefer to not go for a complete abstraction here but rather for convenient means to work with the respective *native* API of existing cache products.
> 
>So IMO, an EhCacheFactoryBean like Dmitriy proposes is certainly a useful addition, exposing EhCache's native Cache object for bean references. I just don't think that trying to abstract that cache API is the right way to go for Spring: There are potentially too many subtle features and semantic details involved. Let's rather expose the full power of the respective native API.
> 
>
>  
>
Having three cache interfaces and corresponding EH-CACHE implementations 
in Acegi Security puts me in a bit of a position to comment about this. 
I fully agree with Juergen - the subtle variations between caches exist 
and it's of questionable value trying to come up with a 
one-size-fits-all interface. In Acegi Security we expose a simple 
project-specific interface, such as:

public interface UserCache {
    public UserDetails getUserFromCache(String username);
    public void putUserInCache(UserDetails user);
    public void removeUserFromCache(String username);
}

If people really need cache pluggability within their own projects, they 
can expose project-specific interfaces to the cache (as above) and then 
write a simple implementation that just does casting and passes through 
to the cache engine.

In relation to Spring loading and configuring the cache engines, there 
is a lot of value in this. We've had two issues emerge with EH-CACHE 
loading after web context refreshes, and then null pointer exceptions 
with the fix. Thus it would be better if we could interface with a cache 
engine Spring worries about managing, and users already know how to 
configure. Due to widespread use, such bugs are likely to be ironed out 
quickly, and projects such as Acegi Security can provide more 
implementations of their own project-specific cache interfaces, given 
Spring takes care of the engine-specific mechanics.

Best regards
Ben