Terracotta Discussion Forums

I've been experimenting with Terracotta and Hibernate and have gotten the Shared, Detached Sessions strategy working. I have a simple app that persists a new object and stores the detached object into a distributed Ehacache. My persistence abstraction's update routine doesn't reattach the persistent object. All it does is make sure that the provided object is already in the distributed cache. The system operates on the objects found in the shared cache. Periodically, the system will do a "flush" which reattaches the Hibernate object and commits things to the database. As advertised, this model cuts down on trips to the database because the update operations only affect shared memory and don't hit the database. I discussed this model with a colleague of mine and he pointed out what might be a fatal flaw in this strategy.

In a standard Hibernate environment, the updates are wrapped in a transaction. If Hibernate, or any other part of the system, throws an exception prior to the transaction completeing everything gets rolled back. The database looks the same as it did before and you typically throw away the object you tried to persist and read a fresh one in from the database so as not to reference any bad state. In the detached session model there are no transactions. If one bit of code modifies a shared object in an incorrect way then the entire cluster sees that incorrect state. That sounds like a bad thing. If the error is an "invalid data" type of issue, then the flushes will probably fail if the database has the right constraints in place. If the error is a "we should forget my changes to the object because some other part of the system failed" type of problem, the system sees state it shouldn't. Is our analysis incorrect? Is there a potential for this strategy to really mess up a system? Are there ways to put a transaction manager around the work without being connected to a database? Can we put a custom transaction around the work that doesn't operate on the shared object until the transaction commits? Any thoughts are appreciated.

It is true that, if I got you right, a problem to a single entry would cause the entire transaction to fail. And that, until that happens, all other threads would see that invalid state.

Yet the main difference between "standard Hibernate" and "detached session" is that multiple threads will never share a managed instance (and should never!) when attached to a Session. When multiple threads access the same entity (by id), they each get a separate copy. Hence changes made by one thread (whether within the boundaries of a transaction or not) aren't visible to others. Whether that data comes straight from the database or from the second level cache.
In the case of "detached session", instances that you put in the cache are (depending on the cache you use) concurrently accessed by all threads. So that one thread (including your flushing one probably) could see an inconsistent state of an entity. So that, to have this pattern work properly you will not only have to implement all your constraints at the model level, but you should also implement the proper locking mechanism so that one thread can actually perform all the mutations required to the model for it be always consistent when another thread manages to access it. Also, should certain operations throw an exception, because of certain constraints being violated for instance, you'll also have to have your model be put manually back into a meaningful state. Basically, the accesses to your model have to be entirely thread safe, which is almost always a better pattern.
If that is currently not the case, I indeed think that your system could potentially be really messed up overtime...

I hope I manage to make myself clear?

@alexsnaps

I see your point about needing to synchronize the model's setters so that mutations can be coordinated. I think you are agreeing with my statement that since the persistable objects are shared and do not operate within a transaction, I need to come up with my own mechanism for detecting invalid changes to the model and manually undo them. That seems like a lot of work that is probably better done using database transactions. Given that shared, detached persistable objects can easily get corrupted due to a lack of transaction support, what is the use case for this pattern? I ran across the pattern in Chapter 6 of the book The Definitive Guide to Terracotta. The author details the implementation and shows how significant saving can be made using the pattern but did not touch upon a particular use case or the affect that a lack of transactions has on the system. I'm wondering if anybody is using the pattern in a real application?