
Terracotta's Journey to the Center of Hibernate - fogus
http://thestrangeloop.com/sites/default/files/slides/ChrisDennis_TerracottaHibernate.pdf
======
ShabbyDoo
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>

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:

"Inﬁnispan is JTA compliant so it plays nice with ongoing transactions"

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

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.

