[hibernate-dev] Ehcache integration

Wed Jul 13 11:49:29 EDT 2011

On Jul 13, 2011, at 11:40 PM, Alex Snaps wrote:

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

this is a different case, since we do not provide a non-internal impl for transaction factory.
(but we may improve this by adding an alternative name for that three like 'jta', 'jdbc', 'cmt')

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