• New Terracotta Integration Module
  • Status: Open
  • 2 Major
  • Resolution:
  • prodmgmt
  • Reporter: marko
  • December 21, 2008
  • 4
  • Watchers: 6
  • March 19, 2010

Description

Requesting support for an Eclipselink Terricotta coordinated cache implementation.

There are several advantages over a Hibernate cache integration.

  • Hibernate only caches serialized objects (not heap objects).
  • Hibernate detached objects only address simple local workflow scenarios.
  • Detached objects do not support lazy loading, further limiting their usefulness. Merging is slow since the whole detached graph is queried from the database.
  • Hibernate does not enforce unique object identity.

Eclipselink on the other hand, has a real heap object cache, that enforces object identity across a distributed coordinated cache. Detaching is implicit, and there really is no need to cache outside the Eclipselink cache (detach), since the Eclipselink cache contains heap objects. Lazy loading exceptions you can get with Hibernate (when navigating detached object graphs) is not an issue with Eclipselink. So you never have the cost of Merging a detached object graph to navigate deeper into the graph.

Eclipselink also has a UnitOfWork session concept for updates that generates a local copy of the cached graph. Only if the copy avoids an optimistic lock exception, and the db transaction is successful, does the cache get updated with (only) the incremental changes from the copy. In the case of a failed transaction, rollback avoids any change to the pre-transaction state in the cache.

Transaction UnitOfWork support may also make possible a generalized mechanism to support transaction rollback of all transaction objects (in-memory pojos as well as persistent orm objects), as well as automatically maintaining cache coherence for committed and rollbacked transactions.

Eclipselink could make it possible to cache any portion of a domain model db (even fully cache it), *and* keep the cached domain transactionally synchronized with a db.
Ideally the later would not be necessary, so that the Terracotta db would be the system of record. But practically speaking relational persistence is also necessary in many cases, particularly for transactional records (orders, accounts, etc…), reporting, and querying.

With Eclipselink you could potentially have the entire db cached by Terracotta, yet transparently maintain synchronization with the db system of record. If there is any doubt that the two are not in synch, you could just drop the Terracotta cache and allow it to naturally get rebuilt.

And besides just the cache, in my opinion Eclipselink has a superior architecture overall and amazing feature set.

As well it is the JPA reference implementation, and combined with Eclipse community support i believe it will gain serious adoption over time.

Also very nice would be integration of the Eclipselink cache into your monitoring/profiling tools.

Here are some related links. In particular, the dzone link gives a comment made by someone that maybe able to help with such an effort. If i can find the time i would also love to help.

http://wiki.eclipse.org/Introduction_to_Cache_(ELUG)#Cache_Coordination_2

http://wiki.eclipse.org/Introduction_to_Cache_(ELUG)#Coordinated_Cache_Types

http://wiki.eclipse.org/Introduction_to_Cache_(ELUG)#Custom_Coordinated_Cache

http://eclipse.dzone.com/articles/introducing-eclipselink#comment-4565

http://wiki.eclipse.org/EclipseLink/DesignDocs/219683

Comments

Steve Harris 2008-12-21

Very interesting. The most important things for getting something like this started are: 1) Community involvement. i.e. someone from eclipselink doing dev on it 2) A specific user/usecase