Closed peilinqian closed 1 year ago
The Datasource
is initialized for each case, leading to multiple XA TM initializations. Even if the initialization of XA TM is removed, the RT does not decrease significantly, and a flame graph needs to be provided for further analysis.
this only a warn log. not problem
please modify CachedDatabaseMetaData.java:getRowIdLifetimeFromOriginMetaData , catch SQLFeatureNotSupportedException to SQLException, because getRowIdLifetime in hikari will throw SQLException!
I don't think the Hikari will change the cause.
Hello , this issue has not received a reply for several days. This issue is supposed to be closed.
Bug Report
For English only, other languages will not accept.
Before report a bug, make sure you have:
Please pay attention on issues you submitted, because we maybe need more details. If no response anymore and we cannot reproduce it on current information, we will close it.
Please answer these questions before submitting your issue. Thanks!
Which version of ShardingSphere did you use?
we find java version: java8, full_version=1.8.0_282 ShardingSphere-5.1.3-SNAPSHOT Commit ID: 7c67365b394d2e3ac562329b550c135c31ea764d Commit Message: Avoid overhead of invoking method in Optional.orElse (#18921) Branch: 7c67365b394d2e3ac562329b550c135c31ea764d Build time: 2022-07-08T19:24:17+0800
Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?
ShardingSphere-JDBC
Expected behavior
ss-jdbc executes sql, the transaction type is local, each time a sql is executed, the xa transaction operation is not performed.
Actual behavior
ss-jdbc executes sql, and the transaction type is local. Each time a sql is executed, the xa transaction operation is performed.
Reason analyze (If you can)
Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.
Example codes for reproduce this issue (such as a github link).