This article has participated in the weekend learning program, click the link to see more details: juejin.cn/post/696572…

There is not much code and the article is not long. It briefly describes the story of the DataSource’s evolution

Output background

Recently, I have been busy with matters related to internal security and encryption of the group, and initially decided to use ShardingSphere

Because there are many projects, the need for compatibility also comes with the need for compatibility between encrypted data sources and dynamic data sources, as well as the compatibility between database tables and encrypted data sources, and so on

Undoubtedly, all of the above are more or less related to data sources, so when dealing with issues such as different compatibility, I am again interested in understanding DataSource, an important concept that has been forgotten by many people

Data query from the old days

A long, long time ago (I don’t know how long), a programmer connecting to a database used to do this

As you can clearly see, DriverManager#getConnection is used to connect to the database directly through the database driver

Setting up a database connection is time consuming, and if the business layer uses this method for every SQL query, it will incur significant system overhead

General system performance requirements, a single request needs to be stable at 200 ms. After testing in the local environment, it takes 300~500 ms to create a database connection in DriverManager form, five minutes to exercise and two hours to take photos?

As systems evolve over time, this approach is unacceptable due to the complexity and performance requirements of the system

The appearance of connection pooling

As some of you may be familiar with, database connection creation consumes resources. Yes, it is similar to thread creation. Since threads can be associated with thread pools, can database connections be placed in a pool?

Yes, there is a pooling technique for database connections called connection pooling. Wouldn’t it be Nice for an application to get a database connection from a connection pool, use it and then put it in the pool? This is the perfect solution to the resource consumption of repeated creation

Behind the seemingly perfect, there is a fatal problem, that is, when you first go to the connection pool to obtain a connection, there is no connection in the connection pool, and you need to go through the creation process

How does connection pooling solve this problem? InitialSize initialSize initialSize initialSize initialSize initialSize initialSize initialSize initialSize initialSize initialSize initialSize initialSize initialSize

If the number of connections in the pool is smaller than the number of connections in the pool, the number of connections in the pool is initialized

Connection pool, thread pool… The core idea of these pooling technologies is that space buys time. Because in the vast majority of cases, space is not that scarce and we are more concerned with the performance of the system

Entry of data source

The connection pool is 🐂 🍺, but a single log is difficult to support. The connection pool does not have the ability to generate connections. Therefore, it needs to cooperate with components such as DriverManager and database drivers to create connections. If you put it in business code like this, wouldn’t you have to wrap another layer?

At this time, I think of a company. What does Sun Company do? In JDBC 2.0, they release a DataSource for the specification constraints

If you want to get a connection to a database, you get it from our DataSource. You don’t have to worry about how the connection pool and connection were created. In fact, the DataSource gets the connection from the connection pool, which is actually created from DriverManager or similar components

DriverManager is a JDBC 1.0 toolkit for calling database drivers. Since JDBC 2.0 has been released, DruidDataSource typically does not rely on DriverManager. Instead, you invoked the database driver in your own implementation class. It is just important to emphasize that the database connection is not necessarily created using DriverManager

DataSource is a standard interface that sun assigns to get database connections. The application is in the middle of the abstraction of database connections. It exists in javax. SQL and is used to get database connections instead of DriverManager

What is the benefit of using DataSource over DriverManager

DriverManager

  • Creating/closing connections in an application hampers application performance

  • Connection pooling is not supported, which wastes system performance by repeatedly creating or closing connections

DataSource

  • Application performance can be greatly improved by not creating/closing connections in the application

  • Provides connection pooling to avoid duplicate creation

Here’s a diagram to illustrate the difference between using DataSource and DriverManager for an application

After the DataSource is available, the database connection, user name, and password are all managed as part of the DataSource property, and the database driver name is filled in, which is automatically loaded at the bottom

DataSource Technical Analysis

Let’s take a look at the DataSource interface description and the corresponding method

The DataSource has only two interfaces, which are used to establish database connections to the DataSource represented by the DataSource

Note here that the CommonDataSource interface, the CommonDataSource interface, is used to define the public methods of the following three data source interfaces

  • Javax.sql.DataSource: Defines the interface for getting basic database connections

  • Javax.mail. SQL. ConnectionPoolDataSource: definition from the database connection pool to obtain the connection interface

  • Javax.sql. XADataSource: Defines the interface to get distributed transaction connections. Generally, it is rare to use XA distributed transaction directly. For specific reasons, refer to distributed 2PC and 3PC transaction models

The first and second types are easier to understand. When Sun defines the specification, it expects you to use a DataSource for common database connections, and a ConnectionPoolDataSource for underlying data sources

The DruidDataSource, for example, implements both orbitals. The class diagram is shown below

DruidDataSource implements both DataSource interfaces in a single class, so the user is not aware of it

To summarize

The article uses a step-by-step way to help us sort out the background of DataSource output

DriverManager, DataSource 2.0, and database connection pooling technology are introduced in JDBC 1.0

Hikari and Druid implemented the DataSource DataSource, and read the source code to get a better understanding of the DataSource design

Creation is not easy, the article see here if it helps, you can point to a concern to support, WISH well. See you next time!