Hello,
I'm working on an application that puts a lot of Hibernate objects into the HTTPSession. My task is to rework the application to work properly in a clustered environment. This involves replicating the HTTPSession to all servers in the cluster, providing failover capability. That is, if the session is started on one server, and that server goes down, another server can pick up the processing of the session because the HTTPSession has been replicated.

Accomplishing the HTTPSession replication involves serializing the attributes within the HTTPSession. This is done at the end of the request filter chain, which is outside of a hibernate session, causing the LazyInitializationException. There are solutions, such as the OpenViewInSession, that provides a means to operate within a hibernate session for the entirety of the filter chain. But this solution isn't the right fit for the problem at hand. Due to the fact that the object graph could get quit large if all the data needs to be loaded.

The ideal solution would be for the state of the object graph to be serialized as is. Meaning, if an object has not been loaded, then the serialized state should reflect this. When the object graph is deserialized, it should take the form of the original object graph where certain object references haven't been loaded.

Is there a way to instruct Hibernate to serialize as is? That is, don't load a reference if it hasn't been loaded, just serialize a proxy object indicating the true state at the time of serialization. Then if that object is referenced after deserialization, it would be loaded.

It seems this would be a common need. Maybe I'm missing something fundamental. My research has come up with solutions suggesting to create a lot of custom classes that allow the serialization of proxy classes. And then when the object is reference perform a remote call to the originating server to load the data. In this scenario, the remote server down, which is why the session failed over.

The other prevalent solution suggests creating a parallel DTO for each Entity. Essentially a duplicate of the data that serializes only the ID of the referenced object, and defines the reference to the true object as transient. A workable solution, it just seems like it's duplication of code to get around a Hibernate short coming.

Best,
Steve

Bump...