I am developing a Swing based rich client application with hibernate and bumped into several constraints which seem hard to avoid with Hibernate and creates ugly hacks and performance bottlenecks in my code.

I appreciate any comments on this post, here are my issues:

Some of these are probably due to the rich nature of the client (what I believe is rich behaviour). The behaviour for CRUD operations is the following:
The user can query objects into a listing screen (search&result screen), which contains only the most necessary data. Then if modifications needed, a detail window appears and the user can modify object properties, embedded objects...etc. Several objects can be modified before saving the data back to the database and the user can create new objects as well with the detail window. The saving procedure is transactional, so either all object modifications & new objects are successfully saved or nothing gets saved. The user can continue work after the save operation and create new objects, modify the saved objects again...etc until it decides to save its work again.
If there is an error during the save operation, the system tells exactly which object has the problem and the user can go back to that object and fix the data in the detail window and restart the save process.
The user can drop the whole set of modifications (since the last save) and re-query the database in order to restart the work.
In my application, several functions can be started in parallel (in separate windows) and they should not interfere with each other (separate transactions).

1)
In some functions I am using fairly large business objects with a large object graph so I use lazy loading for being responsive. My search&result-list screens fetch only the most necessary data (these are helped with join fetch where needed) but most of the data is lazy loaded only if the user opens a detail window on these objects. This is fairly well supported by Hibernate but it results in the need to keep the query session open indefinitely because I don't know when the user wants to load details based on the list. Since, in my application, several functions can be started in parallel (in separate windows) and every function runs in their own transaction so I need to open a separate Session for each of them.

2)
If the user changes a record or creates a new record in a detail window and wants to save data back to the database, the query Session of that window may be corrupted if there is any error during the save. This is because the Session object is not fault tolerant and should be closed and dropped if any exception is thrown during save operations (at least that is what I am told in this forum but several smaller behavioural issues of Hibernate back this). This is a real problem for me because if I close the session due to a save/update error, no lazy loading could be done anymore for the other objects which have not been edited yet by the user. The whole search&result screen should be reloaded with an other Session instance.

To avoid destroying the lazy-loading capability I never save objects in the query Session and I open a dedicated saving Session into which I merge the already existing objects before saving. This works but makes the save process slower. Moreover, after the save has finished, I need to merge the saved objects back to the query session in order to avoid StaleObjectExceptions at the next save operation (the version of the newly saved object is higher than the originally queried object). This further slows the saving process.

Now, I assume, by using a separate saving session in the CRUD functions, I could use a shared/dedicated query session for all function to lower the connection stress on the database but I have no idea how to avoid merging objects between the query session and save session and that results in a lot of selects executed on the database when a CRUD function works on a complex object.

It would be a GREAT if Hibernate Sessions were fault tolerant regarding save/persisting operations and could recover from such errors cleanly. That would make the whole merging/back-merging unnecessary and make my rich CRUD-framework programming very easy with errors at saving. I would simply rollback to the savepoint I set when I start the save process and that's all.

Is there a way to do a merge by not re-querying the whole object in the new session (into which I merge)? This would at least make the process faster for large object graphs.

Would I throw a spanner into the works by suggesting you add the Spring Framework in encompassing your use of Hibernate?

Just that I think that session handling, general handling of objects within this framework and any complex processing (Transaction, etc) would greatly benefit through application of Spring.

My five pence worth but have a look and see what you think.

Mark Dathorne

Thanks Mark, I will think about it. Currently my framework is mostly stable, I would like to speed it up.

In a later version, I may opt for Spring.

I was wondering if EntityManager behaves differently from Session in regards of becoming corrupted for any error at saving objects.

Ok, I am still not sure why you need to have separate sessions though.

i.e. If any error occurs during the transaction you end/rollback the transaction but why use a separate session?

And there is an overhead for additional sessions.

I use a separate session for saving because if there is any error during the save operation (especially when saving a new object), the session which is saving the data gets corrupted and even the rollback doesn`t help in this case. The corrupted session cannot be used for saving objects anymore. This is accepted Hibernate behaviour but makes life very hard.

This is why I open a dedicated new session for the save operation and merge the objects-to-be-saved into it. This session will be closed after the save operation finishes, no matter if it was successful (and was commited) or failed (and was rolled back).