Hibernate 3.2, JDK 1.5

I have a client/server application, where the server side accesses the database and sends back data to the client (swing application). The communication protocol is designed to support serializing of Java objects.

Some of the objects read from the database are marked to be lazy loaded. For example the class 'User' has an attribute address which refers to an instance of the class 'Address'. Currently I have query which lists the users in the users table and returns a list of 'User'.

The issue I have is I try serializing this list I get a 'LazyInitializationException', because I am no longer in session. What approaches do you have to suggest to deal with this issue? For example could I force the object to finish loading dependencies before sending it back and if so how?

The "Open Session in View" pattern typically addresses this in web applications by using a ServletFilter to demarcate a Hibernate Session for each request-response cycle. Perhaps you can try something similar, at least, extending the life of your Hibernate Sessions a bit.

I'll see what I can do. The thing is I am not dealing with a web application. Rather I am dealing with an RMI/RPC type environment where there serialisation happens after my method has returned.

Basically we have the same application type: a Java Swing Client and a server application where Hibernate is used (in fact, an EJB3 application with stateless session beans running on JBoss).

The client application displays a lot of JTables with data overviews on the business objects from the database. These tables are populated not by entity objects, but by DTOs retrieved by non-transactional scalar queries.

The usual behaviour is: the user selects a line from a JTable to get the details of the business object(s), and then the client calls the server to get the underlying business object. In fact this business objects is just some kind of a root object with 5 or even more depending objects (entities!). So, in our application we are loading the complete object graph on client demand by Hibernate and send it back to the client as a graph of detached objects. Then, when the client requests to update the changes made by the user into the database, this object graph is sent back to the server, where a JPA merge call is done on the root object and Hibernate detects which of the entities is dirty and has to be written back to the database.

This kind of operating scenario works very nice; object serialization via RMI and network traffic is no problem. The approach to have some root business object with dependent entities (children) and the decision to have a stateless server led us to work heavily with EAGER loading. Well, to be clear: we also met some situations where the JOINS executed where to heavy. So we made some cuts where we do no use EAGER loading but load the rest of the dependent entities by object navigation or by a separate query.

The JPA merge on detached objects brings some performance problems by nature: Hibernate has to reload all objects from database to do the dirty checks. So, to avoid this, you would have to use a stateful server with long running transactions. This is clearly an alternative, but brings more complexities which the programmers have to master. So, you have to decide which design approach to use.