Polite implementations would certainly like to invoke
The default implementation creates a new Configuration instance. A custom implementation could prepare the instance in a specific way, or use a custom Configuration subclass.
BuildMappings call,
so that it can still extend and modify the mapping information.
LocalSessionFactoryObject lsfb = (LocalSessionFactoryObject) ctx.GetObject("mySessionFactory");.
Uses the SessionFactory that this bean generates for accessing a ADO.NET connection to perform the script.
LocalSessionFactoryObject lsfo = (LocalSessionFactoryObject) ctx.GetObject("mySessionFactory");.
Uses the SessionFactory that this bean generates for accessing a ADO.NET connection to perform the script.
LocalSessionFactoryObject lsfo = (LocalSessionFactoryObject) ctx.GetObject("mySessionFactory");.
Uses the SessionFactory that this bean generates for accessing a ADO.NET connection to perform the script.
ExecuteSchemaStatement
method to treat failures differently.
The default implementation invokes Configuration's BuildSessionFactory. A custom implementation could prepare the instance in a specific way, or use a custom ISessionFactory subclass.
null to indicate an unknown exception.
translate the given exception thrown by a persistence framework to a
corresponding exception from Spring's generic DataAccessException hierarchy,
if possible.
null if the
exception could not be translated.
org.springframework.dao hierarchy. Can be overridden in subclasses.
Can be used to override values in a NHibernate XML config file, or to specify all necessary properties locally.
Note: Do not specify a transaction provider here when using Spring-driven transactions. It is also advisable to omit connection provider settings and use a Spring-set IDbProvider instead.
Such an interceptor can either be set at the SessionFactory level, i.e. on LocalSessionFactoryObject, or at the Session level, i.e. on HibernateTemplate, HibernateInterceptor, and HibernateTransactionManager. It's preferable to set it on LocalSessionFactoryObject or HibernateTransactionManager to avoid repeated configuration and guarantee consistent behavior in transactions.
Unfortunately, Hibernate itself does not define a complete object that represents a type definition, hence the need for Spring's TypeDefinitionBean.
@see TypeDefinitionBean @see org.hibernate.cfg.Mappings#addTypeDef(String, String, java.util.Properties)For example:
<property name="entityCacheStrategies">
<props>
<prop key="MyCompany.Customer">read-write</prop>
<prop key="MyCompany.Product">read-only,myRegion</prop>
</props>
</property>
For example:
<property name="CollectionCacheStrategies">
<props>
<prop key="MyCompany.Order.Items">read-write</prop>
<prop key="MyCompany.Product.Categories">read-only,myRegion</prop>
</props>
</property>
Instead of a single listener object, you can also pass in a list or set of listeners objects as value.
For details on how to make schema update scripts work, see the NHibernate
documentation, as this class leverages the same schema update script support
in
The default exception translator is either a ErrorCodeExceptionTranslator if a DbProvider is available, or a FalbackExceptionTranslator otherwise
The default implementation invokes Configuration's BuildSessionFactory. A custom implementation could prepare the instance in a specific way, or use a custom ISessionFactory subclass.
HibernateTemplate (which by default applies the timeouts) or call
SessionFactoryUtils.applyTransactionTimeout for each created
Hibernate Query object.
An implementation does not need to check the rollback-only flag.
Called after
Should not throw any exceptions but just issue warnings on errors.
This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.
Please do consult the class level documentation for the
null if none.
Requires the object factory to be known, to be able to resolve the object name to an interceptor instance on session creation. Typically used for prototype interceptors, i.e. a new interceptor instance per session.
Can also be used for shared interceptor instances, but it is recommended to set the interceptor reference directly in such a scenario.
DbProvider. Default is "true".
Can be turned off to deliberately ignore an available IDbProvider, to not expose Hibernate transactions as ADO.NET transactions for that IDbProvider.
CreateHibernateTemplate.
Can be overridden in subclasses to provide a HibernateTemplate instance with different configuration, or a custom HibernateTemplate subclass.
org.springframework.dao hierarchy. Will automatically detect
wrapped ADO.NET Exceptions and convert them accordingly.
Note that this is not meant to be invoked from HibernateTemplate code but rather just in plain Hibernate code. Use it in combination with ReleaseSession.
In general, it is recommended to use HibernateTemplate, either with the provided convenience operations or with a custom HibernateCallback that provides you with a Session to work on. HibernateTemplate will care for all resource management and for proper exception conversion.
using (new SessionScope())
{
... do multiple operation, possibly in multiple transactions.
}
At the end of "using", the session is automatically closed. All transactions within the scope use the same session,
if you are using Spring's HibernateTemplate or using Spring's implementation of NHibernate 1.2's
ICurrentSessionContext interface.
Close(),
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Spring.Dao exceptions.
Typically used to implement data access or business logic services that use NHibernate within their implementation but are Hibernate-agnostic in their interface. The latter or code calling the latter only have to deal with domain objects.
The central method is Execute supporting Hibernate access code implementing the HibernateCallback interface. It provides NHibernate Session handling such that neither the IHibernateCallback implementation nor the calling code needs to explicitly care about retrieving/closing NHibernate Sessions, or handling Session lifecycle exceptions. For typical single step actions, there are various convenience methods (Find, Load, SaveOrUpdate, Delete).
Can be used within a service implementation via direct instantiation with a ISessionFactory reference, or get prepared in an application context and given to services as an object reference. Note: The ISessionFactory should always be configured as an object in the application context, in the first case given to the service directly, in the second case to the prepared template.
This class can be considered as direct alternative to working with the raw Hibernate Session API (through SessionFactoryUtils.Session).
LocalSessionFactoryObject is the preferred way of obtaining a reference to a specific NHibernate ISessionFactory.
Not intended to be used directly. See HibernateTemplate.
null if none
org.springframework.dao hierarchy. Will automatically detect
wrapped ADO.NET Exceptions and convert them accordingly.
org.springframework.dao hierarchy. Can be overridden in subclasses.
org.springframework.dao hierarchy. Can be overridden in subclasses.
ISession.Connection().
null if none specified)
HibernateTemplate is aware of a corresponding Session bound to the current thread, for example when using HibernateTransactionManager. If allowCreate is true, a new non-transactional Session will be created if none found, which needs to be closed at the end of the operation. If false, an InvalidOperationException will get thrown in this case.
Default is "false"; if activated, all operations on this template will work on a new NHibernate ISession even in case of a pre-bound ISession (for example, within a transaction).
Within a transaction, a new NHibernate ISession used by this template will participate in the transaction through using the same ADO.NET Connection. In such a scenario, multiple Sessions will participate in the same database transaction.
Turn this on for operations that are supposed to always execute independently, without side effects caused by a shared NHibernate ISession.
close calls and automatically applying
query cache settings and transaction timeouts.
Such an interceptor can either be set at the ISessionFactory level, i.e. on LocalSessionFactoryObject, or at the ISession level, i.e. on HibernateTemplate, HibernateInterceptor, and HibernateTransactionManager. It's preferable to set it on LocalSessionFactoryObject or HibernateTransactionManager to avoid repeated configuration and guarantee consistent behavior in transactions.
Requires the object factory to be known, to be able to resolve the object name to an interceptor instance on session creation. Typically used for prototype interceptors, i.e. a new interceptor instance per session.
Can also be used for shared interceptor instances, but it is recommended to set the interceptor reference directly in such a scenario.
To specify the query region to be used for queries cached by this template, set the QueryCacheRegion property.
The cache region will not take effect unless queries created by this template are configured to be cached via the CacheQueries property.
Default is 0, indicating to use the driver's default.
Default is 0, indicating to use the driver's default.
The default exception translator is either a ErrorCodeExceptionTranslator if a DbProvider is available, or a FalbackExceptionTranslator otherwise
Provides HibernateTemplate's data access methods that mirror various Session methods. See the NHibernate ISession documentation for details on those methods.
Provides HibernateTemplate's data access methods that mirror various Session methods. See the NHibernate ISession documentation for details on those methods.
null).
null)
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
null
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
null
null)
null)
null)
null)
null)
null)
null)
null)
null if not found.
null if not found.
Obtains the specified lock mode if the instance exists.
null if not found
null if not found.
null if not foundnull if not found.
Obtains the specified lock mode if the instance exists.
null if not found
null).
null)
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
null
null
null
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
null
null)
null)
null)
null)
null)
null)
null)
null)
HibernateTemplate is aware of a corresponding Session bound to the current thread, for example when using HibernateTransactionManager. If allowCreate is true, a new non-transactional Session will be created if none found, which needs to be closed at the end of the operation. If false, an InvalidOperationException will get thrown in this case.
Default is "false"; if activated, all operations on this template will work on a new NHibernate ISession even in case of a pre-bound ISession (for example, within a transaction).
Within a transaction, a new NHibernate ISession used by this template will participate in the transaction through using the same ADO.NET Connection. In such a scenario, multiple Sessions will participate in the same database transaction.
Turn this on for operations that are supposed to always execute independently, without side effects caused by a shared NHibernate ISession.
Such an interceptor can either be set at the ISessionFactory level, i.e. on LocalSessionFactoryObject, or at the ISession level, i.e. on HibernateTemplate, HibernateInterceptor, and HibernateTransactionManager. It's preferable to set it on LocalSessionFactoryObject or HibernateTransactionManager to avoid repeated configuration and guarantee consistent behavior in transactions.
The cache region will not take effect unless queries created by this template are configured to be cached via the CacheQueries property.
To specify the query region to be used for queries cached by this template, set the QueryCacheRegion property.
Default is 0, indicating to use the driver's default.
close calls and automatically applying
query cache settings and transaction timeouts.
Requires the object factory to be known, to be able to resolve the object name to an interceptor instance on session creation. Typically used for prototype interceptors, i.e. a new interceptor instance per session.
Can also be used for shared interceptor instances, but it is recommended to set the interceptor reference directly in such a scenario.
Default is 0, indicating to use the driver's default.
The default exception translator is either a ErrorCodeExceptionTranslator if a DbProvider is available, or a FalbackExceptionTranslator otherwise
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
HibernateTemplate (which by default applies the timeouts) or call
SessionFactoryUtils.applyTransactionTimeout for each created
Hibernate Query object.
An implementation does not need to check the rollback-only flag.
Called after
Should not throw any exceptions but just issue warnings on errors.
This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.
Please do consult the class level documentation for the
null if none.
Requires the object factory to be known, to be able to resolve the object name to an interceptor instance on session creation. Typically used for prototype interceptors, i.e. a new interceptor instance per session.
Can also be used for shared interceptor instances, but it is recommended to set the interceptor reference directly in such a scenario.
DbProvider. Default is "true".
Can be turned off to deliberately ignore an available IDbProvider, to not expose Hibernate transactions as ADO.NET transactions for that IDbProvider.
In case of an existing ISession, TemplateFlushMode.Never will turn the hibenrate flush mode to FlushMode.Never for the scope of the current operation, resetting the previous flush mode afterwards.
In case of an existing Session, TemplateFlushMode.Auto will participate in the existing flush mode, not modifying it for the current operation. This in particular means that this setting will not modify an existing hibernate flush mode FlushMode.Never, in contrast to TemplateFlushMode.Eager.
In case of an existing Session, TemplateFlushMode.Eager will turn the NHibernate flush mode to FlushMode.Auto for the scope of the current operation and issue a flush at the end, resetting the previous flush mode afterwards.
In case of an existing Session, TemplateFlushMode.Commit will turn the NHibernate flush mode to FlushMode.Commit for the scope of the current operation, resetting the previous flush mode afterwards. The only exception is an existing flush mode FlushMode.Never, which will not be modified through this setting.
Allows for returning an IList of result objects created within the callback. Note that there's special support for single step actions: see HibernateTemplate.find etc.
CreateHibernateTemplate.
Can be overridden in subclasses to provide a HibernateTemplate instance with different configuration, or a custom HibernateTemplate subclass.
org.springframework.dao hierarchy. Will automatically detect
wrapped ADO.NET Exceptions and convert them accordingly.
Note that this is not meant to be invoked from HibernateTemplate code but rather just in plain Hibernate code. Use it in combination with ReleaseSession.
In general, it is recommended to use HibernateTemplate, either with the provided convenience operations or with a custom HibernateCallback that provides you with a Session to work on. HibernateTemplate will care for all resource management and for proper exception conversion.
Allows for returning the result object created within the callback. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Typically used to implement data access or business logic services that use NHibernate within their implementation but are Hibernate-agnostic in their interface. The latter or code calling the latter only have to deal with domain objects.
The central method is Execute() supporting Hibernate access code which implements the HibernateCallback interface. It provides NHibernate Session handling such that neither the IHibernateCallback implementation nor the calling code needs to explicitly care about retrieving/closing NHibernate Sessions, or handling Session lifecycle exceptions. For typical single step actions, there are various convenience methods (Find, Load, SaveOrUpdate, Delete).
Can be used within a service implementation via direct instantiation with a ISessionFactory reference, or get prepared in an application context and given to services as an object reference. Note: The ISessionFactory should always be configured as an object in the application context, in the first case given to the service directly, in the second case to the prepared template.
This class can be considered as a direct alternative to working with the raw Hibernate Session API (through SessionFactoryUtils.Session).
LocalSessionFactoryObject is the preferred way of obtaining a reference to a specific NHibernate ISessionFactory.
Provides HibernateTemplate's data access methods that mirror various Session methods. See the NHibernate ISession documentation for details on those methods.
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
null).
null)
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
Note: Callback code is not supposed to handle transactions itself! Use an appropriate transaction manager like HibernateTransactionManager. Generally, callback code must not touch any Session lifecycle methods, like close, disconnect, or reconnect, to let the template do its work.
HibernateTemplate is aware of a corresponding Session bound to the current thread, for example when using HibernateTransactionManager. If allowCreate is true, a new non-transactional Session will be created if none found, which needs to be closed at the end of the operation. If false, an InvalidOperationException will get thrown in this case.
Default is "false"; if activated, all operations on this template will work on a new NHibernate ISession even in case of a pre-bound ISession (for example, within a transaction).
Within a transaction, a new NHibernate ISession used by this template will participate in the transaction through using the same ADO.NET Connection. In such a scenario, multiple Sessions will participate in the same database transaction.
Turn this on for operations that are supposed to always execute independently, without side effects caused by a shared NHibernate ISession.
close calls and automatically applying
query cache settings and transaction timeouts.
Such an interceptor can either be set at the ISessionFactory level, i.e. on LocalSessionFactoryObject, or at the ISession level, i.e. on HibernateTemplate, HibernateInterceptor, and HibernateTransactionManager. It's preferable to set it on LocalSessionFactoryObject or HibernateTransactionManager to avoid repeated configuration and guarantee consistent behavior in transactions.
Requires the object factory to be known, to be able to resolve the object name to an interceptor instance on session creation. Typically used for prototype interceptors, i.e. a new interceptor instance per session.
Can also be used for shared interceptor instances, but it is recommended to set the interceptor reference directly in such a scenario.
To specify the query region to be used for queries cached by this template, set the QueryCacheRegion property.
The cache region will not take effect unless queries created by this template are configured to be cached via the CacheQueries property.
Default is 0, indicating to use the driver's default.
Default is 0, indicating to use the driver's default.
The default exception translator is either a ErrorCodeExceptionTranslator if a DbProvider is available, or a FalbackExceptionTranslator otherwise
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
Allows for returning a result object created within the callback, i.e. a domain object or a collection of domain objects. Note that there's special support for single step actions: see HibernateTemplate.find etc.
null if none.
null if none.
AdoExceptionTranslator to use for flushing the
Session on transaction synchronization (can be null; only used when actually
registering a transaction synchronization).
Throws the orginal HibernateException, in contrast to
null if none.
Spring.Dao hierarchy. Note that it is advisable to
handle AdoException specifically by using a AdoExceptionTranslator for the
underlying ADO.NET exception.
null).
null).
This ICurrentSessionContext implementation can also be specified in custom ISessionFactory setup through the "hibernate.current_session_context_class" property, with the fully qualified name of this class as value.
Unbind Hibernate resources (SessionHolder) from
Rebind Hibernate resources from
Can flush transactional sessions to the database.
Note that exceptions will get propagated to the commit caller and cause a rollback of the transaction.
Note that exceptions will get propagated to the commit or rollback caller, although they will not influence the outcome of the transaction.
Normally starting with 0 or 1, with
Higher value can be interpreted as lower priority, consequently the first object has highest priority.
Typically defined as an inner object within a LocalSessionFactoryObject definition, as the list element for the "filterDefinitions" object property. For example:
<objectn id="sessionFactory" type="Spring.Data.NHibernate.LocalSessionFactoryObject, Spring.Data.NHibernate">
...
<property name="FilterDefinitions">
<list>
<object type="Spring.Data.NHibernate.FilterDefinitionFactoryObject, Spring.Data.NHibernate">
<property name="FilterName" value="myFilter"/>
<property name="ParameterTypes">
<props>
<prop key="MyParam">string</prop>
<prop key="MyOtherParam">long</prop>
</props>
</property>
</object>
</list>
</property>
...
</object>
Alternatively, specify an object id (or name) attribute for the inner object, instead of the "FilterName" property.