Spring Configure a DataSource

Java’s javax.sql.DataSource interface provides a standard method of working with database
connections. Traditionally, a 'DataSource' uses a URL along with some credentials to establish a
database connection.

Embedded Database Support

It is often convenient to develop applications by using an in-memory embedded database.
Obviously, in-memory databases do not provide persistent storage. You need to populate your
database when your application starts and be prepared to throw away data when your application
ends.

Spring Boot can auto-configure embedded H2, HSQL, and Derby databases. You need not provide
any connection URLs. You need only include a build dependency to the embedded database that
you want to use.

If you are using this feature in your tests, you may notice that the same database is
reused by your whole test suite regardless of the number of application contexts
that you use. If you want to make sure that each context has a separate embedded
database, you should set spring.datasource.generate-unique-name to true.

For example, the typical POM dependencies would be as follows:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<scope>runtime</scope>
</dependency>

You need a dependency on spring-jdbc for an embedded database to be autoconfigured.
In this example, it is pulled in transitively through spring-bootstarter-data-jpa.


If, for whatever reason, you do configure the connection URL for an embedded
database, take care to ensure that the database’s automatic shutdown is disabled.
If you use H2, you should use DB_CLOSE_ON_EXIT=FALSE to do so. If you use HSQLDB,
you should ensure that shutdown=true is not used. Disabling the database’s
automatic shutdown lets Spring Boot control when the database is closed, thereby
ensuring that it happens once access to the database is no longer needed.

Connection to a Production Database

Production database connections can also be auto-configured by using a pooling DataSource. Spring
Boot uses the following algorithm for choosing a specific implementation:
1. We prefer HikariCP for its performance and concurrency. If HikariCP is available, we always
choose it.
2. Otherwise, if the Tomcat pooling DataSource is available, we use it.
3. If neither HikariCP nor the Tomcat pooling datasource are available and if Commons DBCP2 is
available, we use it.
If you use the spring-boot-starter-jdbc or spring-boot-starter-data-jpa “starters”, you
automatically get a dependency to HikariCP.

You can bypass that algorithm completely and specify the connection pool to use
by setting the configprop:spring.datasource.type[] property. This is especially
important if you run your application in a Tomcat container, as tomcat-jdbc is
provided by default.

 Additional connection pools can always be configured manually. If you define your
own DataSource bean, auto-configuration does not occur.
DataSource configuration is controlled by external configuration properties in spring.datasource.*.
For example, you might declare the following section in application.properties:

spring.datasource.url=jdbc:mysql://localhost/test
spring.datasource.username=dbuser
spring.datasource.password=dbpass
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

You should at least specify the URL by setting the
configprop:spring.datasource.url[] property. Otherwise, Spring Boot tries to autoconfigure
an embedded database.
You often do not need to specify the driver-class-name, since Spring Boot can
deduce it for most databases from the url.

For a pooling DataSource to be created, we need to be able to verify that a valid
Driver class is available, so we check for that before doing anything. In other
words, if you set spring.datasource.driver-class-name=com.mysql.jdbc.Driver, then
that class has to be loadable.

See DataSourceProperties for more of the supported options. These are the standard options that
work regardless of the actual implementation. It is also possible to fine-tune implementationspecific
settings by using their respective prefix (spring.datasource.hikari.*,
spring.datasource.tomcat.*, and spring.datasource.dbcp2.*). Refer to the documentation of the
connection pool implementation you are using for more details.

For instance, if you use the Tomcat connection pool, you could customize many additional settings,
as shown in the following example:
# Number of ms to wait before throwing an exception if no connection is available.
spring.datasource.tomcat.max-wait=10000
# Maximum number of active connections that can be allocated from this pool at the
same time.
spring.datasource.tomcat.max-active=50
# Validate the connection before borrowing it from the pool.
spring.datasource.tomcat.test-on-borrow=true

Connection to a JNDI DataSource

If you deploy your Spring Boot application to an Application Server, you might want to configure
and manage your DataSource by using your Application Server’s built-in features and access it by
using JNDI.
The configprop:spring.datasource.jndi-name[] property can be used as an alternative to the
configprop:spring.datasource.url[], configprop:spring.datasource.username[], and
configprop:spring.datasource.password[] properties to access the DataSource from a specific JNDI
location. For example, the following section in application.properties shows how you can access a
JBoss AS defined DataSource:
spring.datasource.jndi-name=java:jboss/datasources/customers