前提背景:项目前端可选择不同数据库下不同数据源的某张表来查询数据(具体业务暂且不提,知道是前端查询数据库数据即可),所以后端代码中使用到了conn连接池的技术,提高查询效率。
DruidUtil存放conn是map,key为数据源实体的id,value就是conn。
这是数据源实体,注意id是什么:
public class Datasource extends DataBase implements Serializable {
private String id;
private String ipAddress;
private String port;
private String userName;
private String passwd;
private String type;
private String name;
private String connectionMode;
public Datasource(String ipAddress,String port,String username,String passwd,String type,String name,String connectionMode ){
this.id=ipAddress+":"+port;
this.ipAddress=ipAddress;
this.port=port;
this.userName=username;
this.passwd=passwd;
this.type=type;
this.name=name;
this.setConnectionMode(connectionMode);
}
}
在开发环境中,连接池使用的没什么问题,直到测试环境,碰到了一个问题:
选择了mysql数据库下的mysql-A数据源中的table-A表,查询数据之后,再选择mysql数据库下的mysql-B数据源中的table-B表,此时报错:mysql-A.table-B 不存在
疑问:表名确实是第二次选择的数据源(mysql-B)下的表名(table-B),但是为什么前面的库名(schema)会是上一个数据源(mysql-A)的?
查看项目的运行日志信息:发现mysql-A和mysql-B数据源的所有信息都一样,只有名字不一样。在联想到获取druid中的conn,是通过id获取的,而id是由ip+port构成的,那么是不是可以认为:第二次选择的mysql-B数据源,获取的conn实际上是第一次存放的mysql-A的数据源,DruidUtil并没有为mysql-B数据源新建conn?
一番测试后发现确实是因为id的原因导致的这个问题。至于测试过程其实也没什么好贴出来的,无非就是把数据源实体的id更换一下,查看ip和port数据源相同时获取的conn是否一样,修改id保证唯一即可。
修改后的id为 this.id=ipAddress+":"+port+":"+name;
小结:
①项目中的运行日志信息真的非常重要,对于问题的排查很有帮助。如果不是发现数据源除了名字不同,其他都相同的信息,这个问题还真不好找。
②数据源在同一台服务器并且端口相同的情况也是有