Closed wyrzyk closed 2 years ago
I think the issue is in the product. Transactions should be committed explicitly without relying on a hook's side effects. There is probably more than one place that misbehaves this way. I'll try to fix it on the db-replica side (or et least detect and warn about the issue).
I think it may be the issue we observe in the product:
transaction-thread local
.executeUpdate
without callingcommit
.The transaction is never committed on the DualConnection layer, so we never register ReplicaConsistency#write, and we don't store the last write. The following connection assumes the replica is consistent.
Why was the data persistent by the update without calling
commit
?It's because we have a hook:
The hook calls setAutoCommit(true) if the auto-comit was set to false, and according to the Connection docs: "If this method is called during a transaction and the auto-commit mode is changed, the transaction is committed.".