Manik Surtani

Note that this started life as the JPA-like front-end to Infinispan. We ended up abstracting it away to a separate project and this is where Hibernate OGM was born. Read all about it, exciting times ahead.

Yes there is an open JIRA to repackage Infinispan in an OSGi-compliant manner. Willing to help with this? :-)

Yes there is an open JIRA to repackage Infinispan in an OSGi-compliant manner. Willing to help with this? :-)

Yup, Infinispan supercedes JBoss Cache. There won't be any more development on JBoss Cache, all new effort is going to be on Infinispan. We are the same guys who develop both projects. ;)

Hi Peter

1) We support both READ_COMMITTED and REPEATABLE_READ, with READ_COMMITTED being the default. See this config reference link for details on how to configure this. This wiki page has more info as well.

2) Write skews only really occur when using REPEATABLE_READ. READ_COMMITTED just assumes the latest committed version and overwrites anyway; R_R is where you have issues when, for example, updating a shared counter. Write skews are detected easily enough, how they are handled depends on how you configure Infinispan: ignore the write skew and overwrite, or abort the tx.

3) Yes, if using transactions.

4) MVCC is not necessarily timestamp based - all it is, is versioned. So it needs to have a notion of the current, committed version and older versions, etc. Rather than timestamps, we use object refs and compare the object ref of the known, committed version against an update coming in. This is used to detect write skews. In the distributed case, locks are acquired before updates take place to prevent a concurrent object ref swap. These locks are pretty short lived though (duration of the object ref swap, cluster-wide).

HTH
Manik

Fair comment, duly noted.

Thanks for your feedback - if you thought it has to do with Groovy then I have completely missed my target. :-) For the record, Infinispan is an open source data grid platform, written in Java - as mentioned in the first paragraph on the project page (http://www.infinispan.org). I assume you have read this, and the FAQs (http://www.jboss.org/community/wiki/InfinispanFrequentlyAskedQuestions)?

An Infinispan-based implementation for Hibernate is in the pipelines. Already implemented in Hibernate trunk, even. :-)

See https://jira.jboss.org/jira/browse/ISPN-6 and http://opensource.atlassian.com/projects/hibernate/browse/HHH-4103

- Manik

An Infinispan-based implementation for Hibernate is in the pipelines. Already implemented in Hibernate trunk, even. :-)

See https://jira.jboss.org/jira/browse/ISPN-6 and http://opensource.atlassian.com/projects/hibernate/browse/HHH-4103

- Manik

Hi David

We do have some design documentation on the JBoss Cache wiki (including the MVCC locking designs), and while some components are out of date or not as well documented, you should still have a look at the wiki. We do plan to bring it up to date soon, though, but at the end of the day the source code (along with the comments there) will always be your best documentation.

Cheers

Manik

in your scenario it would be all about future proofing. Allocating that mem to the DB would probably be better/faster, but allocating it to the app tier as a cache would mean that you have more flexibility in future to move the DB to a different machine, add more app servers, etc.

in your scenario it would be all about future proofing. Allocating that mem to the DB would probably be better/faster, but allocating it to the app tier as a cache would mean that you have more flexibility in future to move the DB to a different machine, add more app servers, etc.

in your scenario it would be all about future proofing. Allocating that mem to the DB would probably be better/faster, but allocating it to the app tier as a cache would mean that you have more flexibility in future to move the DB to a different machine, add more app servers, etc.

I agree with your comment regarding the increased memory requirements - or alternatively the architectural changes to involve dedicated cache servers and the corresponding complexity in testing that comes with it. But keep in mind that both memory and commodity hardware is cheap.

Think about the alternative: buy a bigger database server, which means throwing out your old one, possibly paying more in license fees if your new DB server has more CPUs, and this still doesn't solve your problem by making the system capable of scaling horizontally, just pushes up your limits. Once these increased limits are hit, you would have to repeat this process all over again, incurring the costs and efforts all over again. And then you have to consider where you end up - what do you do when your DB is already running on the fastest piece of commodity hardware around and you need more performance? Run your DB on a mainframe? :-)

So I don't buy the idea that the increased cost/complexity of introducing caching is a barrier provided caches are warranted in the first place (see last paragraph in the article). As you say - and I agree with you - "... the strategy to cache must not be wholistic". Only use it where you know it is needed.

Cheers

Manik

I'm interested to know what this "official test" is. As the tech lead on JBoss Cache, I can confirm that we have not released any official benchmark tests.