| java.lang.Object org.springframework.orm.hibernate3.AbstractSessionFactoryBean
All known Subclasses: org.springframework.orm.hibernate3.LocalSessionFactoryBean,
Field Summary | |
final protected Log | logger |
Method Summary | |
public void | afterPropertiesSet() Build and expose the SessionFactory. | protected void | afterSessionFactoryCreation() Hook that allows post-processing after the SessionFactory has been
successfully created. | protected void | beforeSessionFactoryDestruction() Hook that allows shutdown processing before the SessionFactory
will be closed. | abstract protected SessionFactory | buildSessionFactory() Build the underlying Hibernate SessionFactory. | protected DataAccessException | convertHibernateAccessException(HibernateException ex) Convert the given HibernateException to an appropriate exception from the
org.springframework.dao hierarchy. | public void | destroy() Close the SessionFactory on bean factory shutdown. | public DataSource | getDataSource() Return the DataSource to be used by the SessionFactory. | public Object | getObject() Return the singleton SessionFactory. | public Class | getObjectType() | final protected SessionFactory | getSessionFactory() Return the exposed SessionFactory. | protected boolean | isExposeTransactionAwareSessionFactory() Return whether to expose a transaction-aware proxy for the SessionFactory. | public boolean | isSingleton() | protected boolean | isUseTransactionAwareDataSource() Return whether to use a transaction-aware DataSource for the SessionFactory. | public void | setDataSource(DataSource dataSource) Set the DataSource to be used by the SessionFactory.
If set, this will override corresponding settings in Hibernate properties.
If this is set, the Hibernate settings should not define
a connection provider to avoid meaningless double configuration.
If using HibernateTransactionManager as transaction strategy, consider
proxying your target DataSource with a LazyConnectionDataSourceProxy.
This defers fetching of an actual JDBC Connection until the first JDBC
Statement gets executed, even within JDBC transactions (as performed by
HibernateTransactionManager). | public void | setExposeTransactionAwareSessionFactory(boolean exposeTransactionAwareSessionFactory) Set whether to expose a transaction-aware current Session from the
SessionFactory's getCurrentSession() method, returning the
Session that's associated with the current Spring-managed transaction, if any.
Default is "true", 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.
Turn this flag off to expose the plain Hibernate SessionFactory with
Hibernate's default getCurrentSession() behavior, supporting
plain JTA synchronization only. | public void | setJdbcExceptionTranslator(SQLExceptionTranslator jdbcExceptionTranslator) Set the JDBC exception translator for the SessionFactory,
exposed via the PersistenceExceptionTranslator interface. | public void | setUseTransactionAwareDataSource(boolean useTransactionAwareDataSource) Set whether to use a transaction-aware DataSource for the SessionFactory,
i.e. | public DataAccessException | translateExceptionIfPossible(RuntimeException ex) Implementation of the PersistenceExceptionTranslator interface,
as autodetected by Spring's PersistenceExceptionTranslationPostProcessor. | protected SessionFactory | wrapSessionFactoryIfNecessary(SessionFactory rawSf) Wrap the given SessionFactory with a proxy, if demanded. |
logger | final protected Log logger(Code) | | Logger available to subclasses
|
afterSessionFactoryCreation | protected void afterSessionFactoryCreation() throws Exception(Code) | | Hook that allows post-processing after the SessionFactory has been
successfully created. The SessionFactory is already available through
getSessionFactory() at this point.
This implementation is empty.
throws: Exception - in case of initialization failure See Also: AbstractSessionFactoryBean.getSessionFactory() |
beforeSessionFactoryDestruction | protected void beforeSessionFactoryDestruction()(Code) | | Hook that allows shutdown processing before the SessionFactory
will be closed. The SessionFactory is still available through
getSessionFactory() at this point.
This implementation is empty.
See Also: AbstractSessionFactoryBean.getSessionFactory() |
buildSessionFactory | abstract protected SessionFactory buildSessionFactory() throws Exception(Code) | | Build the underlying Hibernate SessionFactory.
the raw SessionFactory (potentially to be wrapped with atransaction-aware proxy before it is exposed to the application) throws: Exception - in case of initialization failure |
destroy | public void destroy() throws HibernateException(Code) | | Close the SessionFactory on bean factory shutdown.
|
getDataSource | public DataSource getDataSource()(Code) | | Return the DataSource to be used by the SessionFactory.
|
getObject | public Object getObject()(Code) | | Return the singleton SessionFactory.
|
getSessionFactory | final protected SessionFactory getSessionFactory()(Code) | | Return the exposed SessionFactory.
Will throw an exception if not initialized yet.
the SessionFactory (never null ) throws: IllegalStateException - if the SessionFactory has not been initialized yet |
isExposeTransactionAwareSessionFactory | protected boolean isExposeTransactionAwareSessionFactory()(Code) | | Return whether to expose a transaction-aware proxy for the SessionFactory.
|
isSingleton | public boolean isSingleton()(Code) | | |
isUseTransactionAwareDataSource | protected boolean isUseTransactionAwareDataSource()(Code) | | Return whether to use a transaction-aware DataSource for the SessionFactory.
|
setDataSource | public void setDataSource(DataSource dataSource)(Code) | | Set the DataSource to be used by the SessionFactory.
If set, this will override corresponding settings in Hibernate properties.
If this is set, the Hibernate settings should not define
a connection provider to avoid meaningless double configuration.
If using HibernateTransactionManager as transaction strategy, consider
proxying your target DataSource with a LazyConnectionDataSourceProxy.
This defers fetching of an actual JDBC Connection until the first JDBC
Statement gets executed, even within JDBC transactions (as performed by
HibernateTransactionManager). Such lazy fetching is particularly beneficial
for read-only operations, in particular if the chances of resolving the
result in the second-level cache are high.
As JTA and transactional JNDI DataSources already provide lazy enlistment
of JDBC Connections, LazyConnectionDataSourceProxy does not add value with
JTA (i.e. Spring's JtaTransactionManager) as transaction strategy.
See Also: AbstractSessionFactoryBean.setUseTransactionAwareDataSource See Also: HibernateTransactionManager See Also: org.springframework.transaction.jta.JtaTransactionManager See Also: org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy |
setExposeTransactionAwareSessionFactory | public void setExposeTransactionAwareSessionFactory(boolean exposeTransactionAwareSessionFactory)(Code) | | Set whether to expose a transaction-aware current Session from the
SessionFactory's getCurrentSession() method, returning the
Session that's associated with the current Spring-managed transaction, if any.
Default is "true", 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.
Turn this flag off to expose the plain Hibernate SessionFactory with
Hibernate's default getCurrentSession() behavior, supporting
plain JTA synchronization only. Alternatively, simply override the
corresponding Hibernate property "hibernate.current_session_context_class".
See Also: SpringSessionContext See Also: org.hibernate.SessionFactory.getCurrentSession See Also: org.springframework.transaction.jta.JtaTransactionManager See Also: HibernateTransactionManager See Also: org.springframework.orm.hibernate3.support.OpenSessionInViewFilter See Also: org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor |
setUseTransactionAwareDataSource | public void setUseTransactionAwareDataSource(boolean useTransactionAwareDataSource)(Code) | | Set whether to use a transaction-aware DataSource for the SessionFactory,
i.e. whether to automatically wrap the passed-in DataSource with Spring's
TransactionAwareDataSourceProxy.
Default is "false": LocalSessionFactoryBean is usually used with Spring's
HibernateTransactionManager or JtaTransactionManager, both of which work nicely
on a plain JDBC DataSource. Hibernate Sessions and their JDBC Connections are
fully managed by the Hibernate/JTA transaction infrastructure in such a scenario.
If you switch this flag to "true", Spring's Hibernate access will be able to
participate in JDBC-based transactions managed outside of Hibernate
(for example, by Spring's DataSourceTransactionManager). This can be convenient
if you need a different local transaction strategy for another O/R mapping tool,
for example, but still want Hibernate access to join into those transactions.
A further benefit of this option is that plain Sessions opened directly
via the SessionFactory, outside of Spring's Hibernate support, will still
participate in active Spring-managed transactions. However, consider using
Hibernate's getCurrentSession() method instead (see javadoc of
"exposeTransactionAwareSessionFactory" property).
WARNING: When using a transaction-aware JDBC DataSource in combination
with OpenSessionInViewFilter/Interceptor, whether participating in JTA or
external JDBC-based transactions, it is strongly recommended to set Hibernate's
Connection release mode to "after_transaction" or "after_statement", which
guarantees proper Connection handling in such a scenario. In contrast to that,
HibernateTransactionManager generally requires release mode "on_close".
Note: If you want to use Hibernate's Connection release mode "after_statement"
with a DataSource specified on this LocalSessionFactoryBean (for example, a
JTA-aware DataSource fetched from JNDI), switch this setting to "true".
Else, the ConnectionProvider used underneath will vote against aggressive
release and thus silently switch to release mode "after_transaction".
See Also: AbstractSessionFactoryBean.setDataSource See Also: AbstractSessionFactoryBean.setExposeTransactionAwareSessionFactory See Also: org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy See Also: org.springframework.jdbc.datasource.DataSourceTransactionManager See Also: org.springframework.orm.hibernate3.support.OpenSessionInViewFilter See Also: org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor See Also: HibernateTransactionManager See Also: org.springframework.transaction.jta.JtaTransactionManager |
wrapSessionFactoryIfNecessary | protected SessionFactory wrapSessionFactoryIfNecessary(SessionFactory rawSf)(Code) | | Wrap the given SessionFactory with a proxy, if demanded.
The default implementation simply returns the given SessionFactory as-is.
Subclasses may override this to implement transaction awareness through
a SessionFactory proxy, for example.
Parameters: rawSf - the raw SessionFactory as built by AbstractSessionFactoryBean.buildSessionFactory() the SessionFactory reference to expose See Also: AbstractSessionFactoryBean.buildSessionFactory() |
|
|