02-02-2010

Trying to get Spring + Hibernate + Terracotta working.  Learned something about Terracotta and its Master-Worker support.  Any exceptions that are thrown from within the call() method are returned to the call via shared space.  This means that any exception that can be thrown must be instrumented so it can be shared in Terracotta.  I'm guessing you don't want to have to instrument a whole exception hierarchy so it is probably best to have a few selected Exceptions that are sharable and rethrow the error in terms of those exceptions. 

I've been watching the distributed cache stats and I see plenty of activity on the WorkUnit side but nothing on the Master side.  Things seem to be working so I'm guessing that Ehcache is distributed but I cannot account for the lack of Master cache statistics. I did see a stack trace in the dev console so maybe that is the issue?

The idea of using detached instances is that you store the persistent objects in a shared cached, probably keyed by primary key and object type, and do not do a commit until you want the state to be reflected in the database.  Question: if we use Spring's AOP-based transaction management, can we delay controlling the commit?  To reattach and object use session.saveOrUpdate(foo) to flush Hibernate's cache followed by a comit: session.getTransaction().commit().

I had to make Vehicle's setters synchronized otherwise Terracotta complained about not having a lock to work with.

I got the detached Hibernate sessions to work.  What I did was to refactor the VehicleRepository such that only create, delete and flush had the Spring transaction annotations on them.  I also refactored the repository to place the Vehicle into the distributed cache when one is created.  On the repository, I added a flush() method which has to be called whenever the program wants to write an object out to the db.   Seems to work as advertised with the updates not hitting the database, saving a bunch of time.

Just added optimistic locking to the model.  The test even got an instance of a failed update due to a version issue.  Yay!

Looks like that you have to:

• put a Terracotta lock on the object that manipulates the shared objects, in this case the WorkUnit
• make the WorkUnit.call() method synchronized so that a Terracotta shared lock can be started
• it appears that you need both of the above or Terracotta complains that access outside the scope of a shared lock has been attempted
• no Hibernate TIM is needed.  The Hibernate TIM is for the L2 cache, which doesn't save as much as detached sessions do and introduces issues around stale data

After discussing the technique with Ben, he noticed that updates that are incorrect some how corrupt everybody's view because things are shared and there are no transaction semantics in play.