【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.1-8BP
【问题描述】
java应用，连接ob，单个事务里，进行多表修改出现以下异常。仅特定数量的特定数据会发生这个异常。其他数据行修改都没有问题。
WARN com.zaxxer.hikari.pool.ProxyConnection - DatebookHikariCP - Connection com.mysql.cj.jdbc.ConnectionImpl@45d37bcd marked as broken because of SQLSTATE(08003), ErrorCode(0)。
所执行的sql如下：
sql.txt (11.2 KB)
该批次总共修改了13个商品。修改其他商品无类似现象。 当仅修改其中任意7个商品时，不会报错。超过7个就会报错。
可以使用obdiag进行一下sql解析收集下信息，并发出来看一下
SQL性能问题, 此处env中的trace_id对应gv$ob_sql_audit的trace_id
obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’, trace_id=‘xx’}”
trace id获取方法：
1）设置trace信息
SET ob_enable_show_trace=‘ON’;
2）执行sql。
3）获取上个命令的trace
select last_trace_id();
确认下：一共13个update语句，当你单条sql依次执行，执行到第8条sql就开始报上名的错误么
不是依次执行，是一批次提交13条update语句执行。
当一批次提交超过8条，就会报上面的错误。
不超过8条，不会报错
emm。这个单纯黑屏使用sql没法复现。 生产上，这些sql都被回滚了。也找不到trace_ide。
黑屏开启事务，执行这些sql是没问题的
不是。超时时间120s。 我这立马就抛出异常了
连接异常 SQLSTATE 值 含义 08003 连接不存在。
刚刚我本地测试了下， 直接2881端口直连主副本，发现是不报错的。
补充下。 上述sql中的2个表，主副本在不同机器
感觉是obProxy的bug···
我们用的obProxy版本是： 4.2.1.0-11。
晚点，再部署个4.3.2版本的obproxy试试
先升级一下新版obproxy试试。
obproxy已经迭代很多年了，这种问题我感觉不会出现 
obproxy升级到4.3.2.问题仍然存在。。 这周踩2个坑了 
可以拿到trace_id么 把报错期间的obproxy日志记录保留一下发出来
麻烦把报错截图也贴出来一下
2024-12-06 17:09:17.329 [http-nio-8681-exec-5] [9b3afffc402886e00023] [ProxyConnection.java:182] WARN com.zaxxer.hikari.pool.ProxyConnection - DatebookHikariCP - Connection com.mysql.cj.jdbc.ConnectionImpl@6b4ae18a marked as broken because of SQLSTATE(08003), ErrorCode(0)
java.sql.SQLNonTransientConnectionException: No operations allowed after connection closed.
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)
at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:73)
at com.mysql.cj.jdbc.ConnectionImpl.rollback(ConnectionImpl.java:1875)
at com.zaxxer.hikari.pool.ProxyConnection.rollback(ProxyConnection.java:396)
at com.zaxxer.hikari.pool.HikariProxyConnection.rollback(HikariProxyConnection.java)
at org.springframework.jdbc.datasource.DataSourceTransactionManager.doRollback(DataSourceTransactionManager.java:344)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processRollback(AbstractPlatformTransactionManager.java:835)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.rollback(AbstractPlatformTransactionManager.java:809)
at org.springframework.transaction.interceptor.TransactionAspectSupport.completeTransactionAfterThrowing(TransactionAspectSupport.java:651)
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:371)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:118)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:749)
at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:88)
这怎么避免呢。 发包的问题，我们也控制不了···
是需要加什么参数做下调整么
