Hibernate is an open source object relational mapping library. Hibernate provides a solution to map database tables to a class. It copies one row of the database data to a class. In the other direction it supports to save objects to the database. Objects are transformed to one or more tables.
Hibernate solves Object-Relational impedance mismatch problems by replacing direct persistence-related database accesses with high-level object handling functions.
Basic classes used while working with Hibernate are:
§ SessionFactory
§ Session
§ Transaction
SessionFactory
A thread safe, immutable cache of compiled mappings for a database. The SessionFactory is created from a Configuration object.
The SessionFactory is an expensive object to create. It like is usually created during application start up. However, unlike the Configuration object, it should be created once and kept for later use. The SessionFactory object is used by all the threads of an application.
SessionFactory object is created per database. Multiple SessionFactory objects (each requiring a separate Configuration) are created when connecting to multiple databases.
Session
A single-threaded, short-lived object representing a conversation between the application and the persistent store.
Session objects are not thread safe. Therefore, session objects should not be kept open for a long time. Applications create and destroy these as needed. Typically, they should be created to complete a single unit of work, but may span many units.
Transaction
Transaction object created from Session. Single-threaded, short-lived object used by the application. A Transaction represents a unit of work with the database (and potentially other systems). Transactions in Hibernate are handled by an underlying transaction manager and transaction.
Instance states
An instance of persistent classes may be in one of three different states
Transient:
The instance is not, and has never been associated with any persistence context (A persistence context is a set of entity instances in which any persistent entity identity is unique). It has no persistent identity.
Persistent:
The instance is currently associated with a persistence context. It has a persistent identity (primary key value) and, perhaps, a corresponding row in the database.
Detached
The instance was once associated with persistence context, a detached instance is an has been persistent, but its Session has been closed. The reference to the object is still valid, and the detached instance might even be modified in this state. detached instance can be reattached to a new Session at a later point in time, making it (and all the modifications) persistent again. Can be reattachment of detached instances using the session.update() or Session.merge() methods
Session and transaction scopes
Session-per-operation: open and close a Session for every simple database call in a single thread
Session-per-request: The most common pattern in a multi-user client/server application. In this model, a request from the client is send to the server (where the Hibernate persistence layer runs), a new Hibernate Session is opened, and all database operations are executed in this unit of work. Once the work has been completed (and the response for the client has been prepared), the session is flushed and closed.
Open Session in View: scope of a Session and database transaction until the "view has been rendered"
Session-per-conversation: The Hibernate Session may be disconnected from the underlying JDBC connection after the database transaction has been committed, and reconnected when a new client request occurs.
Locking:
There are two common strategies when dealing with updates to database records, pessimistic locking and optimistic locking.
Optimistic locking is a strategy where you read a record, take note of a version number and check that the version hasn't changed before you write the record back. Optimistic assumes that nothing's going to change while you're reading it.
Pessimistic Lock is where you lock the record/data for your exclusive use until you have finished with it so that no one can access it in between.
Hibernate Automatic Dirty Check:
Hibernate automatically detects object state changes in order to synchronize the updated state with the database, this is called dirty checking. An important note here is, Hibernate will compare objects by value, except for Collections, which are compared by identity. For this reason you should return exactly the same collection instance as Hibernate passed to the setter method to prevent unnecessary database updates.
Hibernate can perform dirty checks only when the objects are loaded and changed in the scope of a single Session
