The only use case I am really interested in for "simple map based" caching is the test suite. Its the whole reason I did not do the things Strong and I discussed on the other thread already.
Perhaps we move "simple map based" caching impl to the hibernate-testing module? The the test suite can continue to use it but we have explicitly published the intent. And yes I totally agree that we should be driving folks to proper cache integrations, namely the infinispan and/or ehcache integrations. The others (oscache, swarmcache, etc) have been removed already. On 06/08/2011 07:26 AM, Sanne Grinovero wrote: > I always try to understand what's the main reason motivating people to > use it. Likely the zero dependencies, "let's just try one" ? > > We could bake a very simple implementation based as you say on a > ConcurrentHashMap, and implement a simple eviction is simple. But I'm > afraid that offering such a feature would drive away from proper > implementations, which we should encourage to use. > > Sanne > > 2011/6/8 Emmanuel Bernard<emman...@hibernate.org>: >> I always die a little when I see someone using HashtableCacheProvider. >> >> What do you think of removing it entirely. Worse case, we could provide an >> implementation that is backed by ConcurrentHashMap but even with that, we >> would get no eviction policy etc. >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Steve Ebersole <st...@hibernate.org> http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
