Hibernate Persistent Context and Session
The concept of Persistent Context and Session are central to the runtime behavior of Hibernate. Persistent Context is a run time memory area where Hibernate holds the references of objects and Session provides api to interact with the objects. Let's look them into one by one.Persistent Context
At runtime whenever a session is opened and closed, between those open and close boundaries Hibernate maintains the object in a Persistence Context. Think of it like a first level runtime cache which hibernate controls. Hibernate does automatic dirty checking and transactional write-behind for the entity managed in Persistent Context. Hibernate guarantee a scope of Java object identity in this cache. Only one object instance representing a particular database row exists in the cache. Hibernate can extend the persistence context to span a whole conversation.
Let's look at following piece of code. Here you can see the use of Session also.
//Persistent Context 1 Starts Session session1 = HibernateUtil.getSessionFactory().openSession(); Student studentA = (Student)session1.get(Student.class, studentId); Student studentB = (Student)session1.get(Student.class, studentId); if(studentA == studentB){ System.out.println("Objects point to same refrence"); } session1.close(); //Persistent Context 1 Ends //Persistent Context 2 Starts Session session2 = HibernateUtil.getSessionFactory().openSession(); Student studentC = (Student)session2.get(Student.class, studentId); if(studentA == studentC){ System.out.println("Objects point to same refrence"); }else{ System.out.println("Objects do not point to same reference"); } session2.close(); //Persistent Context 2 Ends
In the first case studentA and studentB will point to same object as Hibernate guarantees that against a same id only one object exist in the Persistent context. However in the second case studentA and studentC will be pointing to different objects as there is a different Persistent context. Hibernate does not maintains the guarantee beyond a Persistent Context Scope.
Suppose after closing the session2, let's put all the objects in a set
Set allStudents = new HashSet(); allStudents.add(studentA); allStudents.add(studentB); allStudents.add(studentC);
The set will only have two objects. The good practice is to avoid using detached object in situation like above outside of a persistent context or objects coming from different persistent context. Also make sure that the hashCode() and equals() method are properly overridden.
Important points about Persistent Context:
- Beware that hibernate keeps a snapshot of each persistent entity for dirty checking.
- Keep the size of your persistent context to minimum. Keep an eye to your sql logs. Avoid object graphs.
- Use session.evict(object) to clear big size objects once you are done with it. Use session.clear() when you want to remove all objects.
- Use session.setReadOnly(object,true) you can disable dirty checking for a particular instance.
The biggest problem that comes with ORM solutions are memory issues.
Session
Hibernate provides api through Session object to handle database interaction task. The database interaction task are as follows:
- Basic CRUD operation
- Query Execution
- Control of Transaction
- Management of Persistent Context
To make an object persistent, save is used
Student tempStudent = new Student(); tempStudent.setName("Om Shanti Om"); session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = session.beginTransaction(); session.save(tempStudent); tx.commit(); session.close();
To retrieve the object, we can use either load or get
session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = session.beginTransaction(); //Either use get or load to fetch the entity student = (Student)session.get(Student.class, studentId); //student = (Student)session.load(Student.class, studentId); tx.commit(); session.close();
get() returns null if no database object for the id is found.load() throws ObjectNotFoundException. Also load method may return a proxy and tries to avoid hitting the database.
session = HibernateUtil.getSessionFactory().openSession(); tx = session.beginTransaction(); Student loadStudent = (Student)session.load(Student.class, studentId); //The database hit happens here loadStudent.getName(); tx.commit(); session.close();
Hibernate automatically checks for the changes in the entity and flushes the changes to the database.
session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = session.beginTransaction(); student = (Student)session.get(Student.class, studentId); student.setName("Abhishek"); //No explicit call is made to update the record in database. Still the changes //are flushed automatically tx.commit(); session.close();
Data can be removed by calling delete on
Student loadStudent = (Student)session.load(Student.class, studentId); session.delete(student);
An object has to be loaded in persistence context to use delete. The other option is to use bulk operations which can issue direct deletes.Hibernate can also roll back the identifier of any entity that has been deleted, it you enable the hibernate.use_identifier_rollback configuration option. The object can than be treated as transient object.
After persistence context is closed, item becomes a detached instance. The detached object can be handled using update or merge.If there is already an instance of object in the persistence context an exception is thrown.
Managing Detached Entities
Detached entities can be managed again by calling update.
//update to student done outside of persistent scope student.setName("abc"); session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = session.beginTransaction(); //Reattaching. Hibernate will always issue an update, //even if the object is not dirty //The update can happens after attaching. session.update(student); student.setAddress(…); tx.commit(); session.close();
The detached entity can be attached using lock
//Modification to a detached entity session.setName("abc"); session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = session.beginTransaction(); //Reattaching. Lockmodes are NONE, READ, UPDATE. session.lock(student, LockMode.NONE); //It matters where changes are called. If changes are called before locking only, //the update is not issued student.setAddress("Pune"); tx.commit(); session.close();
Merging
Merging merges the detached instance with the managed instance.
session.setName("oyejava"); session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = session.beginTransaction(); session.merge(student); tx.commit(); session.close();
Merging returns a new managed object. The detached instance remains detached. Merging includes all value typed properties and all additions and removals of elements to any collection. Usually it’s better to discard the detached instance and continue the work with the managed entity.
Back to Hibernate Index
Back To Java Home
Back To Home
Sidebar
Last wiki comments
- AOP: Thanks
- Lalit Bhatt: Superb Collection
- Lalit Bhatt: J2EE training
- Introduction to ORM: timberland shoes
- Introduction to ORM: jordan shoes
- Introduction to ORM: nike air max
- Pune Tourist Spots: KONARK PARK CLOSED
- jQuery Form Validations: Jquery Developer
- Spring Introduction: RG
- SOAP: Re: Assertion
Sidebar
Random Pages
- Comprehensive Overview of Java Technologies
- SOAP
- Pune Hill Forts For Trekking
- Windows Antivirus
- Source Code Control Systems
- JavaFX Data Binding and Trigger
- Introduction to Seam
- CSS - Handling Browser Moods
- Parsers Introduction
- Spring Annotation driven Aspects
- JAXB Validation using Schema
- Spring POJO Aspects
- What markets work on?
- Why projects fail?
- Bharat Band - Jai ho
- The concept of Nation
- Don't hide complexity if it cannot be handled in a robustway
Last blog post comments
-
Bharat Band - Jai ho: How do we protest?
Wed 18 of Aug., 2010 13:13 IST
-
Divided by Destiny: Contact
Fri 23 of July, 2010 16:02 IST
-
Future of Java: thesis writing
Sat 17 of July, 2010 01:50 IST
-
Hang till Death Mr. Kasab: some change
Mon 28 of June, 2010 16:03 IST
-
God Religion : Why we are confused?: Re: Is GOD Necessary?
Tue 15 of June, 2010 17:29 IST
-
God Religion : Why we are confused?: Is GOD Necessary?
Tue 15 of June, 2010 13:06 IST
-
The reason in religion: good
Wed 10 of Mar., 2010 18:30 IST
-
The confusion of Design Patterns: I think at macro level you are right...
Tue 23 of Feb., 2010 03:31 IST
-
The Indian Municipality: Comment
Fri 22 of Jan., 2010 13:20 IST
-
What Government should do?: Re: Review of the Indian Law and Order and Justice Dispensation regime.
Fri 22 of Jan., 2010 13:16 IST
Post new comment