[hibernate-dev] Ehcache integration

Wed Jul 13 10:46:07 EDT 2011

On Jul 11, 2011, at 10:48 PM, Alex Snaps wrote:

> Hey guys,
> I've finished the port of all the Hibernate h2lc from the ehcache
> source base into the hibernate-ehcache module.
> Now, polishing this, I also addressed this mapping from old to new names.
> You can see the simple fix here:
> https://github.com/alexsnaps/hibernate-core/commit/fc5d94e8b0b15b43fc7d5e27db4666626d16bd93
> 
> But I have a couple of questions here:
> - Shouldn't the fact that some mapping happens be logged? Are there
> going to stick around? Shouldn't the user be made aware of the fact
> that he should change his config?

a warning 
> - Second level cache isn't (yet?) using "ServiceInitiator approach",
> is this going to change ?

I don't pre-see it, Steve? 
> - Right now the mapping plan is "weak" in terms of typing since core
> doesn't know anything about hibernate-ehcache. I guess, if second
> level caching also goes the ServiceInitiator path, that will change,
> right ?
> 
> I'll do the pull request as soon as I'm sure it's all ready for it.
> Probably sometime tomorrow.
> Thanks,
> Alex
> 
> On Tue, Jun 21, 2011 at 1:58 PM, Steve Ebersole <steve at hibernate.org> wrote:
>> It would not necessarily require users to change config values.  Just update
>> the code that instantiates the RegionFactories
>> (org.hibernate.cache.internal.RegionFactoryInitiator) to understand the
>> legacy class FQN as well.  Have a look at
>> org.hibernate.engine.transaction.internal.TransactionFactoryInitiator for an
>> example of somewhere else we do that.
>> 
>> On 06/21/2011 04:56 AM, Alex Snaps wrote:
>>> 
>>> Did that... I'll replace internal with ehcache then, as in the infinispan
>>> module. But that would still require existing users to change their config
>>> though!
>>> 
>>> 
>>> On Tuesday 21 June 2011 at 11:39, Strong Liu wrote:
>>> 
>>>> take a look of hibernate-infinispan, we should change hibernate-ehcache
>>>> package name like that, using "internal" in user's configuration file is not
>>>> a good ghing
>>>> 
>>>> -----------
>>>> Strong Liu<stliu at hibernate.org (mailto:stliu at hibernate.org)>
>>>> http://hibernate.org
>>>> http://github.com/stliu
>>>> 
>>>> On Jun 21, 2011, at 4:42 PM, Alex Snaps wrote:
>>>> 
>>>>> 
>>>>> On Wednesday 8 June 2011 at 16:47, Strong Liu wrote:
>>>>> 
>>>>>> 
>>>>>> On Jun 8, 2011, at 9:02 PM, Steve Ebersole wrote:
>>>>>> 
>>>>>>> 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.
>>>>>> 
>>>>>> actually this was the next question i was going to ask :D
>>>>>> I have started on this (fyi
>>>>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-6297), but i
>>>>>> can't make it into today's release.
>>>>>> so, if there is no other objection, i will move the concurrent hash map
>>>>>> based 2l cache impl into testing module.
>>>>>> 
>>>>>> btw, the ehcache integration is broken due to the cache spi change, the
>>>>>> RegionFactory impl in ehcache project still uses old hibernate package, i
>>>>>> have filed them a jira.
>>>>> 
>>>>> I'm looking into this and am planning to remove the dependency Ehcache
>>>>> currently has on Hibernate and move all the 2LC code to the
>>>>> Hibernate-ehcache module. I think this addresses two issues:
>>>>> - Packages the right provider code with the right Hibernate version
>>>>> - Avoids the code duplication between the ehcache module&  ehcache core
>>>>> (I had recently have the hibernate-ehcache code wrap the core code, but that
>>>>> leads us into this kind of trouble now).
>>>>> 
>>>>> I've somewhat been wondering about the current packaging though. I see
>>>>> it all is packaged in org.hibernate.cache.internal but configuring
>>>>> hibernate.cache.region.factory_class with a class in an "internal" package
>>>>> seems kinda counterintuitive... or is it only to me ? I wonder whether this
>>>>> couldn't remain the org.hibernate.cache package. Also this wouldn't require
>>>>> users to change their config file. But I guess there was a reason for the
>>>>> move...
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 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<emmanuel at hibernate.org
>>>>>>>> (mailto:emmanuel at 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 at lists.jboss.org (mailto:hibernate-dev at lists.jboss.org)
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org (mailto:hibernate-dev at lists.jboss.org)
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>> 
>>>>>>> --
>>>>>>> Steve Ebersole<steve at hibernate.org (mailto:steve at hibernate.org)>
>>>>>>> http://hibernate.org
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org (mailto:hibernate-dev at lists.jboss.org)
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org (mailto:hibernate-dev at lists.jboss.org)
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> 
>>> 
>> 
>> --
>> Steve Ebersole <steve at hibernate.org>
>> http://hibernate.org
>> 
> 
> 
> 
> -- 
> Alex Snaps <alex.snaps at gmail.com>
> Senior Software Engineer - Terracotta
> http://twitter.com/alexsnaps
> http://www.linkedin.com/in/alexsnaps