[hibernate-dev] Ehcache integration

Alex Snaps alex.snaps at gmail.com
Wed Jul 13 11:40:27 EDT 2011 

On Wed, Jul 13, 2011 at 4:46 PM, Strong Liu <stliu at hibernate.org> wrote:
>
>
> 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

Sounds fair. I already did a pull request.
But I think this warning should be for all these mappings, afaict the
TransactionFactoryInitiator should probably also get it right ?
Should I file a jira for this ?

>> - 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
>
>



-- 
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