Re: [Springframework-developer] oscache

[Dmitriy K. <dko...@ru...>]

I have a EhCacheFactoryBean implementation ready locally, so I could 
commit that tomorrow if there are no objections.

Regards,
Dmitriy.


Ben Alex wrote:

> 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
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer