1. 案例
成某三甲医预约系统， 该项目在2024年初进行上线测试，在正常运行了两天后，业务系统报错：The connection pool has been exhausted, either raise MaxPoolSize (currently 800) or Timeout (currently 15 seconds)。金仓开发人员跟进分析，具体排查步骤如下：
1.1 是否是高并发导致的问题
首先是对业务系统进行了梳理，用户业务系统图如下：
通过对用户现场业务系统的分析，错误是业务系统报出的，业务系统处理第三方消息平台发送的请求，第三方消息平台收集签到机和其它设备发送的请求。业务系统高峰期时，同时请求的请求可以达到10条左右。并发量并不大，排除并发量导致的连接池爆池；
1.2 查询服务器端的连接数
金仓数据库系统表：sys_stat_activity中,记录了每个连接的信息，可以通过如下的语句来查询具体业务的连接数：
select state,query from pg_stat_activity where application_name='ksql';
通过加入定时命令，每隔1秒钟都会查询一下对应业务开启的数据库连接数。在业务量最大时，查询到的连接数达到了800个。并且大多数连接的状态为：Idle in transcation，意味着有大量连接开启了事务，但没有任何操作。是因为连接数池上限过小的问题吗？继续将连接池的上限修改，修改为所允许的最大值。结果连接数依旧可以达到连接上限1200。上述现象不符合驱动kdbndp连接池的循环使用机制。这里需要介绍一下金仓驱动kdbndp的连接池机制：
1.2.1 Kdbndp连接池-连接池状态
连接池有三个计数器：
Idle:空闲连接计数器
Busy:正在使用连接计数器
Waiting:等待获取连接对象计数器
1.2.2 连接池中无连接-申请连接流程
1.2.3 连接池已经存在连接-申请连接流程
1.2.4 连接池释放连接---应用退出
1.2.5 连接池释放连接---连接空闲达到设置时间(默认5分钟)
1.2.6 连接池满-处理流程
1.2.7 连接池参数介绍
Pooling：
是否开启连接池，true：开发连接池，false:关闭连接池，默认值：true
Minimum Pool Size
连接池保持最小连接数,默认值：0
Maximum Pool Size
连接池可以创建连接额最大数，默认值：100
Connection Idle Lifetime
空闲连接空闲时间达到的时间值，到达该时间值时，可以回收该连接，默认值：300(秒)
Connection Pruning Interval
空闲连接回收之前等待时间，默认值：10(秒)
从连接池设计的机制来看，一般连接使用结束之后，是释放回到连接池中；而现场问题中存在大量创建物理连接，将连接池撑爆的现象存在。而且大量物理连接的状态为：Idle in transcation，至此，我们找到了导致连接池爆池的原因。
1.3 分析Idle in transcation
Idle in transcation：当数据连接处于"Idle in transcation"状态时，意味着连接已经开启了事物，但没有任何操作(如提交或回滚)来结束这个事务。我们将KingbaseES+sugar框架的结构图梳理出来，进一步的定位问题，结果图如下：
业务流程访问数据库的数据经过了如下步骤：
1> 定义实体数据模型，实体模型模型是编写程序的依据；
2>业务系统调用SqlSugar接口，创建对象时，业务代码编写人员可以指定使用SqlSugar的模式，推荐使用的是单例模式SqlSugarScope，该模式是线程安全的。在创建对象的时候，指定访问的数据库是哪一家的，DbType。Kdbndp中有一个参数DbModeType，指定使用哪种数据库模式，两者有异曲同工之妙；这个时候，我们也指定了我们访问的数据库，访问数据库使用的连接参数等信息；
3>还是调用SqlSugar接口，SqlSugar会将对应接口的操作，映射、翻译为对应的sql语句，调用Kdbndp的执行接口，将语句发送到服务器端；
4>服务器端执行之后，执行结果又通过Kdbndp的功能接口，回到SqlSugar,根据映射关系，将结果存放至模型对象中，业务系统通过获取模型对象中的数据，完成业务数据展示的处理流程。
上述流程中，步骤二中，创建单例模式的访问对象，这个引起了sugar开发人员和金仓开发人员的关注。在SqlSugar创建单例模式时，整个的创建使用流程如下：
在创建单实例模式中，开始了事务，在使用结束之后，需要提交事务，使用commit接口CommitTran()，提交事务，释放Kdbndp连接对象；如果只是将sqlsugar单实例的对象释放，不使用提交事务接口完成释放的话，KdbndpConnection连接不会被释放，这样就导致了数据库中连接处于:Idle in transcation的现象；再次调用创建单实例模式对象，采用同样的流程，连接数开始逐渐的累加起来，直到出现爆池的错误。
分析之后，梳理用户的业务代码，果然是在开启事物之后，调用完成退出时没有做commit操作，导致Kdbndp连接无法回到连接池，无法循环使用连接池中连接而导致爆池。
调整业务代码，在释放sqlsugar单实例对象时，做事务提交退出操作。修改之后，连接池中的物理连接保持在20个左右，不再出现爆池的错误。循环使用连接池的连接，导致服务器端相关资源消耗下降至原来的1/60。每次任务的提交速度提升了200ms。
现场问题解决了，此过程中，了解了kingbase+sugar的一些基础，在进一步使用中您会发现，
SqlSugar和人大金仓优点：
1、 功能更新的及时性，因为两家公司深入合作，彼此产品有新功能的退出，能在第一时间互相沟通，及时发布；
2、 屏蔽差异化，采用该方案，可以在金仓的多个模式(pg、oracle、mysql)上开发，不用关注模式会带来额外的配置；
3、 开发的高效性，采用ORM框架，缩短了开发周期，屏蔽了差异化，业务迁移和开发的成本都会降低；
4、 实时的技术支持，以在多个项目中得到验证，双方的高效合作，为用户的定制开发、问题定位提供及时的技术支持。