I've used Hibernate quite a bit over the years. Here's my attempt at summarizing the slide deck: 1. Terracotta makes for a nice, highly-concurrent cache plug-

I've used Hibernate quite a bit over the years. Here's my attempt at summarizing the slide deck: 1. Terracotta makes for a nice, highly-concurrent cache plug-in to Hibernate. 2. Hibernate has a few seemingly un-necessary synchronization blocks that can be modified at classload time by one of Terracotta's integration modules. I don't doubt #1 and hope to one day try out Terracotta as a distributed read-write DB cache. [And, more importantly, as a write-behind cache!]. #2 is interesting to me, but most corporate systems developers have bigger fish to fry than trying to suck additional performance out of a caching implementation. Those doing high-volume websites or very low latency financial apps might think much differently, however. Infinispan is JBoss's (Owner of Hibernate) closest competitive offering: http://www.jboss.org/infinispan http://www.jboss.org/infinispan Infinispan does not currently support persistent distributed objects, so its use is more limited than Terracotta. However, if you are using Hibernate, you are persisting to a RDBMS anyway, so what do you care? One interesting point about Infinispan: "Infinispan is JTA compliant so it plays nice with ongoing transactions" http://www.infoq.com/news/2009/05/infinispan http://www.infoq.com/news/2009/05/infinispan From a Terracotta forum post six weeks ago, "JTA is now on the roadmap": http://forums.terracotta.org/forums/posts/list/15/2340.page http://forums.terracotta.org/forums/posts/list/15/2340.page Most people use Hibernate along with JTA to provide painless transaction roll-backs. Caching makes this more difficult because an aborted transaction can result in a dirty cache unless the cache also participates in the transaction. Hibernate's caching policies allow a developer to state his/her comfort level with this risk in exchange for performance improvements. A huge percentage of Hibernate users care more about correctness than absolute transaction speed. An extra 10% improvement isn't worth a few support tickets/week, especially if (A) those bugs appear transient and (2) they cause user distress beyond just a broken app (an insurance policy quoted at the wrong rate, etc.). An interesting point implicit in this slide deck is that Hibernate is long overdue for a refactoring. Integration with Spring isn't as easy as one might hope. Instantiating IoC-injected entities ought to be an out-of-the-box configuration, but it requires AOP or some yucky Hibernate hacks involving statics. I have run into several other IoC-unfriendly practices as well. Cleaning up the various means of customization would yield significant developer benefit.