How Atomic are Mysql Transactions given multiple connections?

Question

I checked related questions, the answer is kinda "yes, very atomic".

But Im going more specific, because those questions were not that specific and so the answers:

1. MySQL/INNODB
2. Several connections at the "same" time
3. A transaction probably WRITING the same tables (even more, the same queries).
4. Only one database
5. No lock table will be done at all
6. . No nested transactions
7. No memcache or any othe similar system, everything as simple as possible.
8. I believe we are using "serializable isoloation, not low level"

In this scenario, are we garanteed by Mysql engine that data integrity will be mantained, or going to specific cases:

• Those "at the same time " writings will be queued?

• Rollback in fact will work as spected.

• readings at "the same time" will find a consistency int the state for those writings?

My simple concerns is that if "commits" and "rollbacks" inside transcations of different connections are atomic or they just make a mess :-)

Thanks.

Answer 1

The "commit" will end a transaction.

It's the transaction isolation level that really determines whether

• all statements executed in the context of a transaction are based on a consistent point-in-time snapshot at the beginning of the transaction (REPEATABLE READ and SERIALIZABLE), or whether

• each statement within the transaction will see changes committed by other transactions ala Oracle (READ COMMITTED), or whether

• each statement will see changes made by other transactions that are not yet committed ala SQL Server dirty reads (READ UNCOMMITTED)

To answer your questions:

The "at the same time writings" will be applied when locks can be obtained. If no other session holds incompatible locks, then locks are obtained, and changes can be applied.

Rollback will work as expected, that is, a transaction ended with a ROLLBACK statement will revert any changes that were applied, the locked rows will be returned to the state they were in at the beginning of the transaction, and locks will be released. (This also includes any DML changes applied by triggers.) Note that this applies ONLY to InnoDB. Any changes applied to MyISAM tables will have already been committed as if by an Oracle-style autonomous transaction.

The "at the same time reads" will each be from a consistent snapshot (with REPEATABLE READ or SERIALIZABLE transaction isolation level.)

NOTE The "commits" and "rollbacks" don't happen "inside transactions", they CONCLUDE a transaction, they mark the end of a transaction. The consistent snapshot at the start of the transaction is gone; the next transaction will get its own consistent snapshot. Those operations aren't best described as "atomic", but they won't, in and of themselves, make a mess.

It's the InnoDB locking mechanism that prevents conflicting changes. If two simultaneous sessions are attempting to make a change to the same row (one session overwriting changes made by the other), at least one of the transactions will wait to obtain the lock held by the other transaction. When the lock is released by the first transaction, the second transaction can obtain the lock, and proceed with its changes; it is free to overwrite changes just made by the other session.

Whether things wind up as a mess really depends on the design of the transactions, and what qualifies as a mess.