RE: [Springframework-developer] oscache

[March, A. <am...@so...>]

Your points are well taken and my example of hibernate is a bit =
different situation than spring is in.  Caching is an integral part of =
hibernate that they have thankfully made pluggable. =20

Spring IoC is more like a service provider with really good glue.  I can =
think of plenty of examples where I would like access to the "native" =
API of a particular service and not have to be hindered by an overly =
simplistic abstract API.

Obviously I was more interested in getting feedback on OSCache than =
thinking about the issue ;)

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On =
Behalf
> Of Ben Alex
> Sent: Thursday, September 16, 2004 2:52 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] oscache
>=20
> j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> >>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:
>=20
> public interface UserCache {
>     public UserDetails getUserFromCache(String username);
>     public void putUserInCache(UserDetails user);
>     public void removeUserFromCache(String username);
> }
>=20
> 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.
>=20
> 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.
>=20
> Best regards
> Ben
>=20
>=20
>=20
> -------------------------------------------------------
> 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