I have recently joined a project where we are using Hibernate 3.1, with MySQL 4.1.16 (Connector/J 3.1.12) with the Spring Framework 1.2.6 in a web app that is quite data intensive.

We are using the Spring DAO Hibernate template to manage the entities.

We are using the Spring OpenSessionInView interceptor to manage the opening and closing of Hibernate sessions per web request.

We are using the default ehcache settings, and the default cglib settings for lazy loading.

We are not using any transaction management at all

Our domain model is quite large and complex - mapping about 100 entities to about as many tables - with collections and bi-directional relationships

We do not expect a high volume of usage - about 15 simultaneous user (web) sessions at any given time.

We are using lazy loading by default, but over time the development team has found that some entity relationships do not work with lazy loading switched on - they get exceptions thrown during the rendering of JSP pages - and so they have disabled it for those particular relationships.

My immediate question is this - do you see any reason why lazy loading would not work despite using the OpenSessionInView Interceptor? Under what conditions would this kind of behavior be displayed? Which configuration files would help determine why this is happening? And what could be done to make sure lazy loading works as expected.

My second question is regarding caching, memory usage and overall efficiency. Hibernate does not like more than one thread using a session. The "Open Session In View" pattern espoused by Spring ensures that a current session is available for the duration of a web request. This implies that a) a new session is being opened and closed for each request, which may be a bit expensive, and b) all objects loaded during a request are stored in memory - and stay there until they are garbage collected - for each request.

Would it make more sense to have one Hibernate Session per web session - so there is only one cache of objects per user session. The actual access to database CRUD operations through the Hibernate session could be synchronized to prevent threading issues.

Any thoughts?

-- Vihung

Don't, its useless and confusing. It adds no value to Hibernate3 APIs. http://hibernate.org./42.html



Why? Hibernate3 has this functionality built-in: http://hibernate.org./43.html



A recipe for disaster, use transactions as described here: http://hibernate.org/42.html

I am not too sure about the exact history of the project, but I know they recently moved from Hibernate 2 to Hibernate 3. Would that explain why these tings are being used?

How would you recommend transitioning to the alternatives?