I'm not sure how to achieve consistent read across multiple SELECT
queries.
I need to run several SELECT
queries and to make sure that between them, no UPDATE
, DELETE
or CREATE
has altered the overall consistency. The best case for me would be something non blocking of course.
I'm using MySQL 5.6 with InnoDB and default REPEATABLE READ
isolation level.
The problem is when I'm using RDS DataService beginTransaction
with several executeStatement
(with the provided transactionId
). I'm NOT getting the full result at the end when calling commitTransaction
.
The commitTransaction
only provides me with a { transactionStatus: 'Transaction Committed' }
..
I don't understand, isn't the commit transaction fonction supposed to give me the whole (of my many SELECT
) dataset result?
Instead, even with a transactionId
, each executeStatement
is returning me individual result... This behaviour is obviously NOT consistent..
With SELECT
s in one transaction with REPEATABLE READ
you should see same data and don't see any changes made by other transactions. Yes, data can be modified by other transactions, but while in a transaction you operate on a view and can't see the changes. So it is consistent.
To make sure that no data is actually changed between selects the only way is to lock tables / rows, i.e. with SELECT FOR UPDATE
- but it should not be the case.
Transactions should be short / fast and locking tables / preventing updates while some long-running chain of selects runs is obviously not an option.
Issued queries against the database run at the time they are issued. The result of queries will stay uncommitted until commit. Query may be blocked if it targets resource another transaction has acquired lock for. Query may fail if another transaction modified resource resulting in conflict.
Transaction isolation affects how effects of this and other transactions happening at the same moment should be handled. Wikipedia
With isolation level REPEATABLE READ
(which btw Aurora Replicas for Aurora MySQL always use for operations on InnoDB tables) you operate on read view of database and see only data committed before BEGIN
of transaction.
This means that SELECT
s in one transaction will see the same data, even if changes were made by other transactions.
By comparison, with transaction isolation level READ COMMITTED
subsequent selects in one transaction may see different data - that was committed in between them by other transactions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With