- First, DBCP is creating a single JDBC connection through the MySQL driver. This connection will point to the master until set to read-only at which point it will switch over to the slave.
- Second, Spring is getting a connection from the pool and writing to the debug log that it has acquired a connection. Because the connection has not yet been set to read-only mode, it will route queries to the master.
- Third, Spring is changing the connection over to read-only mode at which point queries will be routed to the slave.
- Next, your application (or iBatis or w/e) is given the connection to perform some work with the database.
- After you return control to Spring, the transaction on the connection will be committed. Because the connection is in read-only mode, you can see the transaction debug message showing that queries will be routed to the slave server.
- Finally, the connection is reset before being returned to the pool. The read-only mode is cleared and the last log message once again reflects that the connection will route queries to the master server.
The issue with that is that the MySQL replication driver will attempt to reconnect to the master each time the connection is returned to the pool. This happens when read-only mode is cleared. The simplest workaround I can see for this situation is to use a separate data source (and transaction manager) for the master and the slaves. You can them specify (along with read-only if you desire) the name of the datasource/transactionmanager in the annotation,
135
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
