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.
This factory bean will by default expose a transaction-aware SessionFactory
proxy, letting data access code work with the plain Hibernate SessionFactory
and its getCurrentSession() method, while still being able to
participate in current Spring-managed transactions: with any transaction
management strategy, either local or JTA / EJB CMT, and any transaction
synchronization mechanism, either Spring or JTA. Furthermore,
getCurrentSession() will also seamlessly work with
a request-scoped Session managed by OpenSessionInViewFilter/Interceptor.
Requires Hibernate 3.0.3 or later. Note that this factory will always use
"on_close" as default Hibernate connection release mode, for the reason that
this is appropriate for most Spring-based applications (in particular when
using Spring's HibernateTransactionManager). Hibernate 3.0 used "on_close"
as its own default too; however, Hibernate 3.1 changed this to "auto"
(i.e. "after_statement" or "after_transaction").