Page History
...
| Warning |
|---|
Please don't change this the property "hibernate.current_session_context_class" unless you really know what you are doing. It has huge impact on the software architecture. Changing the configuration without changing parts of DSpace's source code will probably result in a miss functioning installtion. |
Read Only Context
The Context object can be set to a read only mode for enhanced performance when processing many database objects in a read-only fashion.
Curation Context (Curator.curationContext())
A context object built to be shared between Curation tasks.
Database Interaction (before DSpace 6.x)
All Database actions require the presence of a Context object.
All DSOs are constructed with a Context object. The context object provides access to the database connections to create/retrieve/update/delete DSOs.
The context object is used to authorize access to particular actions.
Individual DSOs implement an update() method. This method calls org.dspace.storage.rdbms.DatabaseManager.update(). This is a helper class that helps to construct the SQL for a DSO.
Data Access Objects (introduced in DSpace 6.x)
The concept of a Data Access Object (DAO) was introduced in DSpace 6 to provide an optimization layer between the DSpace code and the DSpace database.
In DSpace 6, Hibernate was implemented as the DAO. The DAO concept would allow for a framework other than Hibernate to be implemented in the DSpace code base.
Here is the interface for the GenericDAO in DSpace 6: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/core/GenericDAO.java
Hibernate (introduced in DSpace 6.x)
DSpace 6 introduced hibernate (http://hibernate.org/orm/) as an object relational mapping layer between the DSpace database and the DSpace code.
Objects accessed by hibernate are registered in the hibernate.cfg.xml file. DSO properties and relationships can be inferred from the database schema.
The following class provides a hibernate implementation of the GenericDAO interface.
Because hibernate has a mechanism for automatically updating content that has changed, the save() method is not implemented.
The save to the database is invoked when Context.commit() is called.
...
Context Configurations
The DSpace Context Object can be constructed as a read-only context or a batch context. This mode determines how hibernate will flush changes to the database. It is good behavior to store the old context mode before changing it and to set it back to the old mode when you're done with your work. This reduces problems when code parts that needs to be able to update stored content calls parts of DSpace's code that uses a read only or a batch mode.
Read Only Context in DSpace 6
The Context object can be set to a read only mode for enhanced performance when processing many database objects in a read-only fashion. Objects read by a read only context are not intended to be modified. The context object should not be committed.
The read only context is intended for data security. Implementations using this context should not be able to accidentally save changes.
Batch Context in DSpace 6
Hibernate provides a mechanism to submit a large batch of changes to a database in a memory-efficient manner.
See https://docs.jboss.org/hibernate/orm/3.3/reference/en-US/html/batch.html
Database Interaction (before DSpace 6.x)
All Database actions require the presence of a Context object.
All DSOs are constructed with a Context object. The context object provides access to the database connections to create/retrieve/update/delete DSOs.
The context object is used to authorize access to particular actions.
Individual DSOs implement an update() method. This method calls org.dspace.storage.rdbms.DatabaseManager.update(). This is a helper class that helps to construct the SQL for a DSO.
Data Access Objects (introduced in DSpace 6.x)
The concept of a Data Access Object (DAO) was introduced in DSpace 6 to provide an optimization layer between the DSpace code and the DSpace database.
In DSpace 6, Hibernate was implemented as the DAO. The DAO concept would allow for a framework other than Hibernate to be implemented in the DSpace code base.
Here is the interface for the GenericDAO in DSpace 6: https://github.com/DSpace/DSpace/blob/
...
master/dspace-api/src/main/java/org/dspace/core/
...
...
Hibernate (introduced in DSpace 6.x)
DSpace 6 introduced hibernate (http
The hibernate commit is implemented in the following manner
...
...
...
org/orm/) as an object relational mapping layer between the DSpace database and the DSpace code.
Objects accessed by hibernate are registered in the hibernate.cfg.xml file. DSO properties and relationships can be inferred from the database schema.
The following class provides a hibernate implementation of the GenericDAO interface.
Because hibernate has a mechanism for automatically updating content that has changed, the save() method is not implemented.
...
Hibernate Annotations in DSpace
Additional relationships can be explicitly declared using Hibernate annotations.
The Hibernate Session (Cache) and the Context Object
Hibernate will intelligently cache objects in the current Hibernate Session, allowing for optimized performance. Each Hibernate Session opens a single database connection when it is created, and holds onto it until the session is closed. A Session may consist of one or more Transactions.
In DSpace, the Hibernate Session (and its Transactions) is managed by the HibernateDBConnection object. (NOTE: This class is perhaps unfortunately named as it manages the process of obtaining a database connection from Hibernate, via a Session. It does not represent a single database connection.)
- See
- https://github.com/DSpace/DSpace/blob/dspace-6_x.1/dspace-api/src/main/java/org/dspace/core/HibernateDBConnectionAbstractHibernateDAO.javajava#L43-L45
The DSpace Context object has methods (like uncacheEntity() and reloadEntity()) which can manage objects cached within this Hibernate Session (via HibernateDBConnection).
Some care is needed to properly utilize the Hibernate cache. Objects are loaded into the Session cache on access. Objects are not removed from the cache until one of the following occurs:
- The Hibernate Session's Transaction is committed (e.g. via a call to
Context.commit()orContext.complete()) - The Hibernate Session's Transaction is rolled back (e.g. via a call to
Context.abort()) - The object is specifically "evicted" (i.e. uncached) from the Hibernate Session (e.g. via a call to
Context.uncacheEntity())
Be aware, once an object is removed (detached) from the Session cache, it will need to be reloaded from the database before it can be used again! This can be achieved via Context.reloadEntity() or by querying for the object again via its Service.
Development tips regarding Hibernate Session
A few tips on working with Hibernate Sessions (all gleaned from https://developer.atlassian.com/confdev/development-resources/confluence-architecture/hibernate-sessions-and-transaction-management-guidelines)
save to the database is invoked when Context.commit() is called.
The hibernate commit is implemented in the following manner
Hibernate Annotations in DSpace
Additional relationships can be explicitly declared using Hibernate annotations.
The Hibernate Session (Cache) and the Context Object
Hibernate will intelligently cache objects in the current Hibernate Session, allowing for optimized performance. Each Hibernate Session opens a single database connection when it is created, and holds onto it until the session is closed. A Session may consist of one or more Transactions.
In DSpace, the Hibernate Session (and its Transactions) is managed by the HibernateDBConnection object. (NOTE: This class is perhaps unfortunately named as it manages the process of obtaining a database connection from Hibernate, via a Session. It does not represent a single database connection.)
The DSpace Context object has methods (like uncacheEntity() and reloadEntity()) which can manage objects cached within this Hibernate Session (via HibernateDBConnection).
Some care is needed to properly utilize the Hibernate cache. Objects are loaded into the Session cache on access. Objects are not removed from the cache until one of the following occurs:
- The Hibernate Session's Transaction is committed (e.g. via a call to
- Hibernate sessions are not thread-safe
- Therefore, any new DSpace code must ensure it is not attempting to share objects or Sessions between threads. Instead, pass around UUIDs, so the new thread can load the referenced object in a new Session.
- The more objects you load during the lifetime of a Session, the less efficient each query will be
So, be sure to useContext.commit()orContext.uncacheEntitycomplete()) when you are done with an object - (recommendation: offer very specific/limited guidance on when to call uncacheEntity())
- Because Hibernate has built-in Session caching, it is not recommended to cache objects elsewhere in your code. If you must perform other caching, store UUIDs instead
- Caching objects elsewhere is likely to result in a
LazyInitializationExceptionif the object (cached elsewhere) outlives its Session. See "Common Hibernate Error Messages" below.
- Caching objects elsewhere is likely to result in a
Context Configurations
The DSpace Context Object can be constructed as a read-only context or a batch context. This mode determines how hibernate will flush changes to the database.
Read Only Context in DSpace 6
Objects read by a read only context are not intended to be modified. The context object should not be committed.
The read only context is intended for data security. Implementations using this context should not be able to accidentally save chages.
Do read only connections also have optimized performance?
Batch Context in DSpace 6
Hibernate provides a mechanism to submit a large batch of changes to a database in a memory-efficient manner.
...
- The Hibernate Session's Transaction is rolled back (e.g. via a call to
Context.abort()) - The object is specifically "evicted" (i.e. uncached) from the Hibernate Session (e.g. via a call to
Context.uncacheEntity())
Be aware, once an object is removed (detached) from the Session cache, it will need to be reloaded from the database before it can be used again! This can be achieved via Context.reloadEntity() or by querying for the object again via its Service.
Development tips regarding Hibernate Session
A few tips on working with Hibernate Sessions (all gleaned from https://developer.atlassian.com/confdev/development-resources/confluence-architecture/hibernate-sessions-and-transaction-management-guidelines)
- Hibernate sessions are not thread-safe
- Therefore, any new DSpace code must ensure it is not attempting to share objects or Sessions between threads. Instead, pass around UUIDs, so the new thread can load the referenced object in a new Session.
- The more objects you load during the lifetime of a Session, the less efficient each query will be
- So, be sure to use
Context.commit()orContext.uncacheEntity()when you are done with an object - (recommendation: offer very specific/limited guidance on when to call uncacheEntity())
- So, be sure to use
- Because Hibernate has built-in Session caching, it is not recommended to cache objects elsewhere in your code. If you must perform other caching, store UUIDs instead
- Caching objects elsewhere is likely to result in a
LazyInitializationExceptionif the object (cached elsewhere) outlives its Session. See "Common Hibernate Error Messages" below
- Caching objects elsewhere is likely to result in a
The Life-cycle of a DSO with Hiberate
...
Overview
Content Tools