Hibernate Basics

As a persistence service, Hibernate must work with multiple databases and within various application environments. Supporting these variations requires Hibernate to be highly configurable to adapt to different environments. After all, running a standalone application can be quite different from running a web application. Differences in obtaining database connections, for instance, can be significant. Hibernate is typically configured in two steps.

First, you configure the Hibernate service. This includes database connection parameters, caching, and the collection of persistent classes man–aged by Hibernate. Second, you must provide Hibernate with information about the classes to be persisted. Persistent class configuration allows you to bridge gaps between the class and databases.

Although it's commonly used within J2EE application servers, such as WebSphere and JBoss, Hibernate can also be used in standalone applications. Requirements vary for different environments, and Hibernate can be configured to adapt to them. Hibernate works with various support services, such as connection pools, caching services, and transaction managers. It also lets you maintain additional support services by implementing simple interfaces.

Hibernate supports a number of different configuration methods and options to support these scenarios. Configuring all of Hibernate's properties can be overwhelming, so we'll start slowly. Before we jump into configuration, look at figure , which shows the major Hibernate classes and configuration files.

 

The light gray boxes in the figure are the classes your application code will use most often. The dark gray boxes are the configuration files used by the Configuration class to create the SessionFactory , which in turn creates the Session instances. Session instances are your primary interface to the Hibernate persistence service.

SessionFactory

The SessionFactory is created from a Configuration object, and as its name implies it is a factory for Session objects.

Configurer c = new Configurer();

// load XML file and parse the XML file

c.confgurer(“/hibernate.cfg.xml”);

//the entire XML file data is stored in sessionFactory class object. Infact SessionFactory class is a representation of hibernate.cfg.xml file

SessionFactory sf = c.buildSessionFactory();

The SessionFactory is an expensive object to create. It, like the Configuration object, 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. It is a thread safe object. One SessionFactory object is created per database. Multiple SessionFactory objects (each requiring a separate Configuration) are created when connecting to multiple databases. The SessionFactory can also provide caching of persistent objects.

Session

A Hibernate Session object represents a single unit-of-work for a given data store and is opened by a SessionFactory instance. You must close Sessions when all work for a transaction is completed.

A single-threaded, short lived object representing a conversation between the application and the persistent store.

Wraps a JDBC connection factory for transaction, For each client request create a session object and destroy after the task (session.close()).

SessionFactory.openSession() method creates one Session object, means when openSession() method is requested one database connection object is created and internally assigned to Session object. Session means internally it is a JDBC Connection object.

Session s = sf.openSession();

Hibernate internally saves every object into session cache first and then converts into sql operation and that too SQL operation is not immediately executed on database first they are all added into Statements batch and then executes the batch.

After creating the Session object, create one java Bean object.

Customer c = new Customer();

c.setID(1);

c.setName(“Vardhan”);

s.save(c);

s.flush();

t.commit();

Session object first stores customer object into one collection object with id as key, and then convert’s customer object into SQL statement/INSERT statement. The insert statement is added to batch.

Whenever s.flush() method is called, flush() method is equal to statement.executeBatch() method. It flushes all SQL statements to DB. And when finally t.commit() method is called, DB permanently stores the record into DB.