Minidao 1.5.1 - I think this is a lax bug

foreword

Minidao hurt me badly, I was about to be carried by the project manager to sacrifice to heaven, but fortunately I found this problem, just record it here!

I just pay attention to this kind of thing. This is my personal opinion and does not represent the whole point of view, but this is a real problem that I have encountered and have!

Our system has a WeChat push message, and the number of push messages per day varies, sometimes more, sometimes less. Our database connection pool uses Durid, and the maximum number of connections is 500. Every time we push an alarm, we find that the number of database connections is around 500, which is basically full.

Later, we modified the configuration on the database connection, but the effect was minimal, so we pointed the finger at Minidao, an open source plug-in for database operation used during development at that time. The version used at that time was 1.5.1, because the system used Minidao after , In many places, there is no need to write SQL for adding, deleting, modifying and checking a single table.

 

Brief description of the problem

Connection pool leak problem

Enter the reference text here. Because minidao 1.5.1 is used in the project, the addition, deletion, modification and checking of hibernate do not require writing sql statements, resulting in a connection pool leak when the program is running, and the number of database connections has been above 300.

For this matter, I will check the source code and test.

 

right way

I still want to make a note here: the version I used is 1.5.1, and now the latest version is 1.6.3, which does not solve this problem, but does not have that class. Did I read it wrong? So I record it.

So I set out to test the Minidao!

1. Write test code

2. Number of database connections before execution

3. The number of database connections after execution

4. Minidao source code

These tests show that database operations using xxxByHiber will generate a connection and will not be closed.

 //*********************test source(数据库中字段设置很小所以抛异常)******************
        for (int i = 0; i < 50; i++) {
		BI_DIM bi_DIM = new BI_DIM();
		if(i > 20)    
                        bi_DIM.setBiz_Table_Name("123====================================================================="+i);
		else
			bi_DIM.setBiz_Table_Name("123===="+i);
		bi_DIM.setDim_Name("测试");
		bi_DIM.setDrill_Info("");
		try {
			dimDao.saveByHiber(bi_DIM);
		} catch (Exception e) {
		        System.err.println("抛异常了"+i+"; info:"+e.getMessage());
		}
	}
	return "";
        //**********************minidao source********************************************
        /**
	 * 根据传入的实体持久化对象
	 */
	public <T> void save(T entity) {
		try {
			getSession().save(entity);
			getSession().flush();
			if (logger.isDebugEnabled()) {
				logger.debug("保存实体成功," + entity.getClass().getName());
			}
		} catch (RuntimeException e) {
			logger.error("保存实体异常", e);
			getSession().close();
			throw e;
		}

	}

I don't think it's possible that you haven't noticed! Regarding the minidao 1.5.1 version, how to solve the problem of connection pool leakage?

This question is a very imprecise mistake!

 

minidao 1.5.1 source code​github.com

Code cloud code warehouse address

 ant dot andot.org

 

I'm just expressing my opinion!