Sqlsessionfactorybuilder, Sqlsessionfactory, sqlsession scope (scope) and life cycle

Last Update:2017-05-26 Source: Internet

Author: User

Tags finally block

Developer on Alibaba Coud: Build your first app with APIs, SDKs, and tutorials on the Alibaba Cloud. Read more ＞

It can be said that each mybatis is centered on a sqlsessionfactory instance. Sqlsessionfactory instances can be built by Sqlsessionfactorybuilder. One is that the sqlsessionfactory can be built in the form of an XML configuration file, and the second is built through the Java API. However, there is a configuration through which all the configurations are implemented through the config instance.

This article is intended to implement the scope and life cycle guidance recommendations MyBatis3.4.1 User Guide by coding. Why do you know the scope and life cycle? Using Sqlsessionfactorybuilder, Sqlsessionfactory, and sqlsession correctly within the scope will allow us to avoid the problems of concurrency in a multithreaded environment. Of course, if you use the dependency (DI) injection Framework (Spring), you don't have to worry about scope issues in your code, because the dependency injection framework will do almost everything for us.

Let's start by looking at User Guide's guidance on the Sqlsessionfactorybuilder scope and life cycle.

Sqlsessionfactorybuilder

This class can be instantiated, used, and discarded, and once the sqlsessionfactory is created, it is no longer needed. Therefore, the optimal range of Sqlsessionfactorybuilder instances is the method scope (that is, local method variables). You can reuse Sqlsessionfactorybuilder to create multiple sqlsessionfactory instances, but it's best not to keep them alive to ensure that all XML parsing resources are open to more important things.

Sqlsessionfactory

Once created, sqlsessionfactory should exist for the duration of the application and there is no reason to clean it up or rebuild it. The best practice for using sqlsessionfactory is not to repeatedly create multiple times during an app run, and rebuilding sqlsessionfactory multiple times is considered a "bad taste" of code. The optimum range of sqlsessionfactory is therefore the application range. There are many ways to do this, and the simplest is to use singleton mode or static singleton mode.

Sqlsession

Each thread should have its own sqlsession instance. The instance of sqlsession is not thread-safe and therefore cannot be shared, so its best scope is the request or method scope. You must never put a reference to a sqlsession instance in a static domain of a class, or even an instance variable of a class. It is also never possible to place references to sqlsession instances in any type of management scope, such as HttpSession in the Serlvet schema. If you are using a WEB framework now, consider sqlsession in a similar scope to the HTTP request object. In other words, each time you receive an HTTP request, you can open a sqlsession, return a response, and close it. This close operation is important, and you should put the shutdown action in the finally block to ensure that the shutdown is performed every time.

You can see from the User Guide that the scope of the official scopes for Sqlsessionfactorybuilder, sqlsessionfactory, and sqlsession are: Method scope, application scope, request, or method scope, respectively. It is easy for beginners to ignore the scope range of the sqlsessionfactory and place them and Sqlsessionfactorybuilder and sqlsession within the method scope. This does not, in itself, lead to Procedural code errors (which can only cause concurrency problems if the sqlsession is placed in the application scope), but this is considered "bad smell". When I first wrote "MyBatis3," I did not read the user guide so much that the code smelled a "bad smell". example, the code is as follows: