Hibernate Thuy, Le Huu. Pentalog VN

Agenda Hibernate Annotations Improving performance – Lazy loading – Fetching Strategies – Dynamic insert, dynamic update – Hibernate mutable – Different between session.get() and session.load() – Caching in hibernate Integrate Hibernate with Other Frameworks

Annotations So far you have seen how Hibernate uses XML mapping file for the transformation of data from POJO to database tables Hibernate annotations is the newest way to define mappings without a use of XML file

Annotations = "stock") public class Stock implements = = "STOCK_ID") public Integer getStockId() { return this.stockId; }

Annotations package com.pentalog.ginet.domain; = "EMPLOYEE") public class @Column(name = "id") private int = "first_name") private String = "last_name") private String = "salary") private int salary; public Employee() {} public int getId() { return id; } public void setId( int id ) { this.id = id; } public String getFirstName() { return firstName; } public void setFirstName( String first_name ) { this.firstName = first_name; } public String getLastName() { return lastName; } public void setLastName( String last_name ) { this.lastName = last_name; } public int getSalary() { return salary; } public void setSalary( int salary ) { this.salary = salary; } JPA annotations in javax.persistence.* Annotation: – Marks this class as an entity bean, so it must have a no-argument constructor that is visible with at least protected Annotation: – allows you to specify the details of the table that will be used to persist the entity in the Annotations: – Each entity bean will have a primary Annotation: – annotation is used to specify the details of the column to which a field or property will be mapped.

Lazy loading Lazy setting decides whether to load child objects while loading the Parent Object – Address child of User class can be made lazy if it is not required – May need to load the Author object for Book parent whenever you deal with the book for online bookshop – Default lazy loading is TRUE

Lazy loading This make sure that the child objects are not loaded unless they are explicitly invoked in the application by calling getChild() method on parent In this case hibernate issues a fresh database call to load the child when getChild() is actually called on the Parent object

Lazy = FetchType.LAZY, mappedBy = "stock") – fetch = FetchType.LAZY – fetch = – LazyCollectionOption.FALSE – LazyCollectionOption.TRUE – LazyCollectionOption.EXTRA

Fetching Strategies Hibernate fetching strategies are used to optimize the Hibernate generated select statement – fetch-”join” = Disable the lazy loading, always load all the collections and entities. – fetch-”select” (default) = Lazy load all the collections and entities. – batch-size=”N” = Fetching up to ‘N’ collections or entities, *Not record*. – fetch-”subselect” = Group its collection into a sub select statement.

Dynamic insert Using dynamic-insert to avoid the include unmodified properties in the SQL INSERT statement Default: dynamic-insert=false

Dynamic update Using dynamic-insert to avoid the include unmodified properties in the SQL UPDATE statement Default: dynamic-update=false

Hibernate mutable Using mutable keyword to avoid the generate unnecessary SQL statements mutable = “false” is declared in class – In Class with mutable=”false” – insert=allow, delete=allow, update=not allow mutable = “false” is declared in collection – In Collection with mutable=”false” – insert=not allow, delete-orphan=not allow, delete=allow, update=allow

session.get() and session.load() Understanding when should use get or load to retrieve the object in order to avoid unnecessary hit to the database. Session.load() – It will always return a “proxy” (Hibernate term) without hitting the database. In Hibernate, proxy is an object with the given identifier value, its properties are not initialized yet, it just look like a temporary fake object. – If no row found, it will throws an ObjectNotFoundException Session.get() – It always hit the database and return the real object, an object that represent the database row, not proxy. – If no row found, it return null.

Caching The first-level cache is the Session cache and is a mandatory cache through which all requests must pass – Objects are cached within the current session and they are only alive until the session is closed Second level cache is an optional cache and first-level cache will always be consulted before any attempt is made to locate an object in the second-level cache – Query-level cache

Caching Concurrency strategies – Read-only – Nonstrict-read-write – Read-write – Transactional