Hibernate version: 3.1

I have a question regarding the efficient usage of hibernate across multiple webapps, EARs etc. If I have multiple applications (WARs for instance) each of which use Hibernate, then should two completely different instances of Hibernate be initialized and run (i.e. one inside the scope of each webapp)? Or should only one instance of hibernate be running on a server across all webapps?

Brad

Hibernate isn't an application, it's a library. It doesn't "run", it's just a pile of methods that you can call.

Each webapp will need access to the hibernate jar. You can reuse the same jar for each webapp if you like.

Perhaps I should rephrase my question. Is it a better idea to have multiple webapps leverage the same SessionFactory (and hence, all webapps' will share the same Hibernate configuration file and will have to combine all of their mappings into a central location / archive), or to have each webapp instantiate their own SessionFactory.

The question is basically one of deployment / archive configuration, and project organization vs. performance /resource utilitization. Organizationally speaking, it is nicer to have a webapp be completely encapsulated, with a SessionFactory instantiated for that webapp only. But then there's the question of performance, efficiency, and potential conflicts. With performance and efficiency, there's the question of JDBC connection usage, and the resources each Hibernate instance consumes. As far as potential conflicts are involved, what if two webapps have to access the same object/table called MYENTITY. Will two seprate webapps each with their own instance of Hibernate cause a problem accessing the same table? What about unique surrogate database key generation? If each Hibernate instance is generating keys, will there be a conflict?

Is there a standard best-practice? Should each webapp use its own separate SessionFactory and configuraiton, or should each webapp utiltize the same SessionFactory which is bound to JNDI, for instance?

Thanks for your help.

Brad

Judicious use of transactions prevents problems when multiple connections might access the same data. However, the conflicts will happen whether or not you use a single configuration file, because each webapp will have its own pool of connections, and each connection might talk to the same table at various points.

To avoid this (not that you particularly need to), you can use an application server or similar, and have a single application for accessing the database. Other applications would then request data access from that application.

I recommend gonig with separate configuration files. This allows you to have different timeouts, connection pool sizes, etc. for different webapps. It also means that you can customize which mapping files are loaded by which app, to speed up startup times for apps that need only a small subset of availabe tables. My strategy has been to include a configuration file in each jar that my webapps use, then use either the jar="" attribute (undocumented, unfortunately) of the mapping element in the configuration file, or add the relevant mapping files to the Configuration object programmatically, during webapp startup. So all apps get the UserSecurity jar, several get the EmailRecords jar, and each app will have a small selection of jars specific to itself.

There is no standard for this sort of thing. There are probably as many solutions are there are development teams that have encountered the issue.

Thanks for the reply. Ok, I liked that approach too, as it allowed the webapp to be self-contained. However, there is one aspect of this approach which I'm curious about. What if I have two webapps where each of them have a mapping for the same entity X. What happens if two webapps have a mapping to the same entity, and further, if each webapp is inserting records and each instance of hibernate is generating unique keys, will this be a problem?

Thanks,

Brad

No, not if you use transactions correctly. The exception to this would be if you use the "assigned" id generator (or composite keys), that might get conflicts. But nothing extraordinary, you just code defensively and it'll be fine.

my two cents

assigned ids are generated at the database level so database will take care of potential conflicts. no need to worry about some id being generated if you take the help of database for id generation!