The typical usage will be to register this as singleton factory
(for a certain underlying JDBC DataSource) in an application context,
and give bean references to application services that need it.
Configuration settings can either be read from a Hibernate XML file,
specified as "configLocation", or completely via this class. A typical
local configuration consists of one or more "mappingResources", various
"hibernateProperties" (not strictly necessary), and a "dataSource" that the
SessionFactory should use. The latter can also be specified via Hibernate
properties, but "dataSource" supports any Spring-configured DataSource,
instead of relying on Hibernate's own connection providers.
This SessionFactory handling strategy is appropriate for most types of
applications, from Hibernate-only single database apps to ones that need
distributed transactions. Either HibernateTransactionManager or
JtaTransactionManager can be used for transaction demarcation, the latter
only being necessary for transactions that span multiple databases.
Registering a SessionFactory with JNDI is only advisable when using
Hibernate's JCA Connector, i.e. when the application server cares for
initialization. Else, portability is rather limited: Manual JNDI binding
isn't supported by some application servers (e.g. Tomcat). Unfortunately,
JCA has drawbacks too: Its setup is container-specific and can be tedious.
Note that the JCA Connector's sole major strength is its seamless
cooperation with EJB containers and JTA services. If you do not use EJB
and initiate your JTA transactions via Spring's JtaTransactionManager,
you can get all benefits including distributed transactions and proper
transactional JVM-level caching with local SessionFactory setup too -
without any configuration hassle like container-specific setup.
Note: Spring's Hibernate support requires Hibernate 2.1 (as of Spring 1.0).