[hibernate-dev] JCS Hibernate Region Factory

Thu Aug 21 05:37:32 EDT 2014

Hi Petar,
willing to experiment with it is awesome, but I'm skeptical on that project.

The benchmark I've found on the JCS site is not measuring what
matters; for example the put an get operations are sequential and not
multithreaded, so we have no clue about how it can handle contention
or even smart eviction protocols *during* other concurrent get an put
operations. The strategy of looping that way has also been proven to
be severely misleading, they should better look at microbenchmark
tools like JMH, or especially the reasons for which such tools were
created.

Also there is much more in a caching library than get/put: you need to
manage a limited size of available memory, and it's very likely that
the cost of evicting the wrong entries outshines by large the cost of
a single get/put operation. In other words, it's far more important to
measure how the eviction strategies are effective for a specific
application load.

And the test summarizes all performance with a rough average, as Gil
Tene will explain in his awesome talk about measuring "performance"
[1] you definitely don't want to do that, unless you're building batch
applications (in which case I doubt you'd be using an ORM).

What ultimately matters is the performance that you can get out of
your full application: so your code, your hardware, your model,
Hibernate, the caching library and the integration code you'll write.
How you write that integration code is probably crucial: with Ehcache
and Infinispan we're lucky that those integration points are
maintained directly by experts of the respective technology, I think
that's very important to make the right design choices to understand
the underlying design.

So I don't mean to discourage you, just that it might be a good idea
to study the JCS internals carefully or maybe get advice from the JCS
team; from our side as Hibernate maintainers it would be great to have
an additional option but we can't take this responsibility unless you
or other people interested in JCS can maintain it in future as well,
as Alex and Galder nicely do for Ehcache and Infinispan integrations.

Another option is to keep such code in the Commons JCS repository and
have the JCS team maintain it, that's the strategy followed by
Hazelcast as far as I know.

Note that when I say I'm not liking the benchmark that doesn't imply
that JCS itself is bad, just that the benchmark doesn't give me a
clue. I honestly don't know it, what's great about it? I'm puzzled
that people intend to revive it, when both Ehcache and Infinispan are
well proven, and both are ASL2 as well.. personally I'd rather
contribute to one of these [disclaimer: I actually did contribute to
both projects, recently more on Infinispan but that's beyond caching
reasons].

+1 to work on the JSR107 provider, that would be much more useful I think.

-- Sanne

1 - https://www.youtube.com/watch?v=ZJG-tX7_dRg

On 20 August 2014 19:26, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> Hi Alex,
>
> sure - keep me in the loop when you have the jsr107 provider ready and i'll
> give it and jcs a try.
>
> Cheers
>
>
> 2014-08-20 20:23 GMT+03:00 Alex Snaps <alex.snaps at gmail.com>:
>
>> Petar, thanks, I'll have a look at it!
>> I'll try to clear up some time this week (no promise here though! But if
>> you'd like to help...) to finally finish this jsr107 provider for h2lc and
>> try to test it against the JCS impl. then.
>> That would let you use JCS with Hibernate. If you want a "native" JCS
>> provider though, there'd be more code to write though...
>> Alex
>>
>>
>> On Wed, Aug 20, 2014 at 1:18 PM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> seems like the documentation on the website is too old. So we can ignore
>>> the performance bit. But still, it would be nice to provide a region
>>> factory, so the end-client has the choice whichever they like.
>>>
>>> @Alex: There's a 2.0-SNAPSHOT here:
>>> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-jcs/
>>> and yes, seems like it is JCache complient.
>>>
>>>
>>> 2014-08-20 20:14 GMT+03:00 Alex Snaps <alex.snaps at gmail.com>:
>>>
>>> I'll try avoiding a flame war here... especially as I'm a Terracotta
>>>> employee and working on Ehcache.
>>>> That being said, the FAQ says:
>>>> "I just built both EHCache (1.2-beta4) and JCS (1.2.7.0) from head,
>>>> (...)", where 1.3.0 was released over 7 years ago, I guess "just" has
>>>> relative semantics here.
>>>> Latest stable JCS release is 5 years old now too, so whether you still
>>>> manage to find the Ehcache perf results, or are reading the ones on the JCS
>>>> website... there are, how would I best put it, ... utterly out of date.
>>>>
>>>> On a side note, if the 2.0 release will be 107 compliant, I have a
>>>> JSR-107 caching provider more or less done (missing a couple of things for
>>>> the read-write strategy around collections), but I'd love to test with that
>>>> too then (not necessarily perf only though here).
>>>>
>>>> Anyways, random biased thoughts :)
>>>> Alex
>>>>
>>>>
>>>> On Wed, Aug 20, 2014 at 12:56 PM, Guillaume Smet <
>>>> guillaume.smet at gmail.com> wrote:
>>>>
>>>>> Hi Petar,
>>>>>
>>>>> On Wed, Aug 20, 2014 at 6:36 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>>>> wrote:
>>>>> > I would really like to give apache commons jcs a spin (the FAQ says
>>>>> > performancewise it's faster than EHCache)
>>>>>
>>>>> I don't know JCS but I find it funny they criticize the fact that
>>>>> Ehcache published an old benchmark and that they still have a very old
>>>>> one in their FAQ.
>>>>>
>>>>> It might be interesting to have more recent performance information
>>>>> comparing the latest versions of both before deciding if it's really
>>>>> worth it.
>>>>>
>>>>> --
>>>>> Guillaume
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alex Snaps <alex.snaps at gmail.com>
>>>> Principal Software Engineer - Terracotta
>>>> http://twitter.com/alexsnaps
>>>> http://about.me/alexsnaps
>>>> http://www.devoxx4kids.org/quebec/
>>>>
>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
>>
>>
>> --
>> Alex Snaps <alex.snaps at gmail.com>
>> Principal Software Engineer - Terracotta
>> http://twitter.com/alexsnaps
>> http://about.me/alexsnaps
>> http://www.devoxx4kids.org/quebec/
>>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev