Hibernate.org Community Documentation

- Prev

## Chapter 1. Database Access

## 1.1. JDBC Connections

Hibernate understands how to connect to a database through an interface `org.hibernate.connection.ConnectionProvider`. While `org.hibernate.connection.ConnectionProvider` is considered an extension SPI, Hibernate comes with a number of built-in providers.

### 1.1.1. Using connection pooling

The built-in connection pooling based providers all require the following settings

hibernate.connection.driver_class

  Names the `java.sql.Driver` implementation class from your JDBC provider.

hibernate.connection.url

  The JDBC connection url. See your JDBC provider's documentation for details and examples.

hibernate.connection.username

  The name of the user to use when opening a JDBC `java.sql.Connection`.

hibernate.connection.password

  The password associated with the provided username.

#### 1.1.1.1. Using Hibernate's built-in connection pooling

## Warning

The built-in Hibernate connection pool is not intended for production use. It lacks several features found on any decent connection pool. However, it can be quite useful to get started and in unit testing.

The only additional supported setting for the built-in pooling is the hibernate.connection.pool_size setting which tells the pool how many connections maximum it can keep in the pool.

#### 1.1.1.2. Using c3p0 for connection pooling

To be continued...

#### 1.1.1.3. Using proxool for connection pooling

To be continued...

### 1.1.2. Using `javax.sql.DataSource`

Hibernate can also use a `javax.sql.DataSource` to obtain connections. To do so, Hibernate expects to be able to locate the `javax.sql.DataSource` in `JNDI`. The hibernate.connection.datasource setting tells Hibernate the `JNDI` namespace at which it can find the the `javax.sql.DataSource`.

Generally speaking a `javax.sql.DataSource` is configured to connect to the database using a single set of credentials (username/password). Sometimes, however, the `javax.sql.DataSource` is set up so that the credentials have to be used to obtain a `java.sql.Connection` from it. In these cases applications would specify the credentials via the hibernate.connection.username and hibernate.connection.password settings, which Hibernate would pass along to the `javax.sql.DataSource` when obtaining a `java.sql.Connection` from it.

## 1.2. Database Dialects

A Dialect informs Hibernate of the capabilities of the underlying database. This role is fulfilled by an instance of a `org.hibernate.dialect.Dialect` subclass. The Dialect is one of the most important pieces of information given to the Hibernate `org.hibernate.Sessionfactory` during startup as it allows Hibernate to properly plan how it needs to communicate with the database.

### 1.2.1. Specifying the Dialect to use

The developer may manually specify the Dialect to use by setting the hibernate.dialect configuration property to the name of the specific `org.hibernate.dialect.Dialect` class to use.

### 1.2.2. Dialect resolution

Assuming a `org.hibernate.connection.ConnectionProvider` has been set up according to Section 1.1, “JDBC Connections” then Hibernate will attempt to automatically determine the Dialect to use based on the `java.sql.DatabaseMetaData` reported by a `java.sql.Connection` obtained from that `org.hibernate.connection.ConnectionProvider`.

This functionality is provided by a series of `org.hibernate.dialect.resolver.DialectResolver` instances registered with Hibernate internally. Hibernate comes with a standard set of recognitions. If your application requires extra Dialect resolution capabilities, it would simply register a custom implementation of `org.hibernate.dialect.resolver.DialectResolver` as follows

Example 1.1. Registering a custom `org.hibernate.dialect.resolver.DialectResolver`

        org.hibernate.dialect.resolver.DialectFactory.registerDialectResolver( "org.hibernate.example.CustomDialectResolver" );

Registered `org.hibernate.dialect.resolver.DialectResolver` are prepended to an internal list of resolvers, so they take precedence before any already registered resolvers including the standard one.

### 1.2.3. Custom Dialects

It is sometimes necessary for developers to write a custom Dialect for Hibernate to use. Generally this is as simple as selecting a particular `org.hibernate.dialect.Dialect` implementation that is closest to your needs and subclassing it and overriding where necessary.

Custom dialects may be manually specified as outlined in Section 1.2.1, “Specifying the Dialect to use” as well as registered through a resolver as outlined in Example 1.1, “Registering a custom org.hibernate.dialect.resolver.DialectResolver”.

## 1.3. Database Schema

To be continued...

Copyright © 2004 Red Hat, Inc.

- PrevPreface
- Top of page
- Front page