【YashanDB知识库】由于druid中间件配置导致的YAS-04003 maximum number of open cursors is 1000

本文内容来自YashanDB官网,原文内容请见 https://www.yashandb.com/newsinfo/7802970.html?templateId=1718516

问题现象

某客户的业务(Java框架)运行时报如下异常:

IMG_256

问题的风险及影响

客户的业务无法正常运行

问题影响的版本

所有的yashandb版本

问题发生原因

druid中间件有如下参数,可以控制是否缓存PreparedStatement,客户现场为如下配置:

share-prepared-statements:true

pool-prepared-statements:true

max-open-prepared-statements:100

在此种配置下,jdbc层面的PreparedStatement会被druid中间件缓存,在YashanDB侧,一个缓存未关闭PreparedStatement会被视为一个open cursor。

当这些open cusor达到YashanDB初始化参数OPEN_CURSORS指定的上限后,就会报出YAS-04003 maximum number of open cursors is xxx异常。

解决方法及规避方式

在YashanDB侧增加OPEN_CURSORS初始化参数的值,或者在druid层面修改参数,不再缓存PreparedStatement。例如:

share-prepared-statements调整为false

pool-prepared-statements调整为false

max-open-prepared-statements调整为-1

问题分析和处理过程

在业务报YAS-04003异常时,使用如下语句查询当前YashanDB的open cusor:

select b.sql_text from v$open_cursor a, v$sql b

where a.sql_id = b.sql_id;

并结合v$session,确认是否业务会话。

经验总结

当java框架及中间件将jdbc连接及其涉及的jdbc对象接管后,需要根据java框架及中间件的配置,并结合YashanDB提供的视图,来分析实际的行为。

posted @   YashanDB  阅读(8)  评论(0编辑  收藏  举报
编辑推荐:
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· DeepSeek 解答了困扰我五年的技术问题
· 为什么说在企业级应用开发中,后端往往是效率杀手?
· 用 C# 插值字符串处理器写一个 sscanf
阅读排行:
· [翻译] 为什么 Tracebit 用 C# 开发
· 腾讯ima接入deepseek-r1,借用别人脑子用用成真了~
· Deepseek官网太卡,教你白嫖阿里云的Deepseek-R1满血版
· DeepSeek崛起:程序员“饭碗”被抢,还是职业进化新起点?
· RFID实践——.NET IoT程序读取高频RFID卡/标签
点击右上角即可分享
微信分享提示