1. I can't find "since Hibernate 3.0.1 OpenSessionInView is built-in without having to use Spring..." . What do I need to do special to use this built-in feature?

2. In our Struts->EJB->Hibernate application, we have mutltiple Hibernate session open/close calls made before the requested page is returned to the user. If I understand this correctly using 'OpenSessionInView' pattern the hibernate session would be opened & closed only once. Can anyone comment on performance, memory consumption, server load, connection limitations, connection pool sizes, etc. This would be used to justify this big code modification which would probably involve stripping out all those getCurrentSession() and closeSession() calls in the Data access layer (Dal) classes.

3. Our current hibernate.properties file has the following 'Transaction API' section. What needs to be turned ON or OFF in this file to be able to use the OpenSessionInView pattern?

#######################
### Transaction API ###
#######################
## Enable automatic flush during the JTA beforeCompletion() callback
## (This setting is relevant with or without the Transaction API)

#hibernate.transaction.flush_before_completion

## Enable automatic session close at the end of transaction
## (This setting is relevant with or without the Transaction API)

#hibernate.transaction.auto_close_session

## the Transaction API abstracts application code from the underlying JTA or JDBC transactions
hibernate.transaction.factory_class org.hibernate.transaction.JTATransactionFactory
#hibernate.transaction.factory_class net.sf.hibernate.transaction.JDBCTransactionFactory
## to use JTATransactionFactory, Hibernate must be able to locate the UserTransaction in JNDI
## default is java:comp/UserTransaction
## you do NOT need this setting if you specify hibernate.transaction.manager_lookup_class
#jta.UserTransaction jta/usertransaction
#jta.UserTransaction javax.transaction.UserTransaction
#jta.UserTransaction UserTransaction
#jta.UserTransaction java:/UserTransaction
## to use JCS caching with JTA, Hibernate must be able to obtain the JTA TransactionManager
hibernate.transaction.manager_lookup_class org.hibernate.transaction.JBossTransactionManagerLookup
#hibernate.transaction.manager_lookup_class org.hibernate.transaction.WeblogicTransactionManagerLookup
#hibernate.transaction.manager_lookup_class org.hibernate.transaction.WebSphereTransactionManagerLookup
#hibernate.transaction.manager_lookup_class org.hibernate.transaction.OrionTransactionManagerLookup
#hibernate.transaction.manager_lookup_class org.hibernate.transaction.ResinTransactionManagerLookup




Need help with Hibernate? Read this first:
http://www.hibernate.org/ForumMailingli ... AskForHelp

Hibernate version:

Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using:

The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:

This design pattern is not about performance or scalability, it just helps to avoid mistakes in resource and transaction management code. But probably you will need larger buffer for web server (as large as max content lenght) and max DB connections == max HTTP requests for scalability.

In a Struts->EJB->Hibernate application with the following sample Object hierarchy:

Client
|-ClientGUID
|-FirstName
|-LastName
+-Roles (Map) (lazy=true)
|--RoleCode
|--Role
|
+-AddressRoles (Map) (lazy=true)
|--AddressRoleCode
|--Address

In a typical HTTP request:
* In the business layer with ClientGUID obtained from the Struts ActionForm we fetch the Client object in the DAO (Hibernate session open & close)
* In the business layer we realize we need more of the Client details. And, since accessing them on the retrieved Client object instance gives LazyInstantionException, we use the ClientGUID to lookup the Roles & AddressRoles using the data access layer DAOs(Hibernate session open & close in both cases)

But, with the OpenSessionInView pattern it sounds like for the entire Request-Response cycle there will be only one Hibernate session open & close. On the face of it it seems like this would be a better performer since opening & closing database connections/sessions is an expensive operation.

Also as per your suggestion, putting max db connections i.e. configuring the connection pool with number of connections almost equal to web HTTP requests might be hard to sell and may prove to be a resource hog for the DB server.

Any coments, suggestions?

Yes, it can help to avoid some queries too. But you can close session and commit transaction in controler before "forward" to avoid large buffers and pools. Service layer will be the same as "OpenSessionInView" (no resource management and transaction demarcation), move this stuff to controler servlet or base action.