[hibernate-dev] Ehcache integration

Alex Snaps alex.snaps at gmail.com
Mon Jul 11 10:48:02 EDT 2011


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?
 - Second level cache isn't (yet?) using "ServiceInitiator approach",
is this going to change ?
 - 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




More information about the hibernate-dev mailing list