Hibernate.orgCommunity Documentation
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.
The built-in connection pooling based providers all require the following settings
Names the java.sql.Driver
implementation class from your JDBC
provider.
The JDBC connection url. See your JDBC provider's documentation for details and examples.
The name of the user to use when opening a JDBC java.sql.Connection
.
The password associated with the provided username.
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.
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.
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.
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.
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.
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”.
Copyright © 2004 Red Hat, Inc.