sharding-jdbc read and write separation and use of ReuseExcutor to read and read from the slave library after the write operation

reason

shrding-jdbc In order to maintain the transaction consistency of read-write separation, all read operations after the write operation will be routed to the main library, but there is a situation in the business that the read operation after the write operation is still the read library used. The reason for this is that ReuseExcutor caches Statement. If there is a read operation before the write operation, and its sql is the same as the read operation after the write operation, it will cause two read operations to use one Statement, because the first read operation sharding-jdbc is a Statement constructed from the database data source, so the second read operation also uses the same data source as the first read operation. Thus invalidating the transaction.

solution

Configure the default Executor of mybatis to SimpleExecutor.

Related source code

• org.apache.ibatis.executor.ReuseExecutor
• io.shardingsphere.shardingjdbc.jdbc.core.statement.MasterSlavePreparedStatement

{{o.name}}

{{m.name}}