php - How Atomic are Mysql Transactions given multiple connections? -
i checked related questions, answer kinda "yes, atomic".
but im going more specific, because questions not specific , answers:
- mysql/innodb
- several connections @ "same" time
- a transaction writing same tables (even more, same queries).
- only 1 database
- no lock table done @ all
- . no nested transactions
- no memcache or othe similar system, simple possible.
- i believe using "serializable isoloation, not low level"
in scenario, garanteed mysql engine data integrity mantained, or going specific cases:
those "at same time " writings queued?
rollback in fact work spected.
readings @ "the same time" find consistency int state writings?
my simple concerns if "commits" , "rollbacks" inside transcations of different connections atomic or make mess :-)
thanks.
the "commit" end transaction.
it's transaction isolation level determines whether
all statements executed in context of transaction based on consistent point-in-time snapshot @ beginning of transaction (repeatable read , serializable), or whether
each statement within transaction see changes committed other transactions ala oracle (read committed), or whether
each statement see changes made other transactions not yet committed ala sql server dirty reads (read uncommitted)
to answer questions:
the "at same time writings" applied when locks can obtained. if no other session holds incompatible locks, locks obtained, , changes can applied.
rollback work expected, is, transaction ended rollback statement revert changes applied, locked rows returned state in @ beginning of transaction, , locks released. (this includes dml changes applied triggers.) note applies innodb. changes applied myisam tables have been committed if oracle-style autonomous transaction.
the "at same time reads" each consistent snapshot (with repeatable read or serializable transaction isolation level.)
note "commits" , "rollbacks" don't happen "inside transactions", conclude transaction, mark end of transaction. consistent snapshot @ start of transaction gone; next transaction own consistent snapshot. operations aren't best described "atomic", won't, in , of themselves, make mess.
it's innodb locking mechanism prevents conflicting changes. if 2 simultaneous sessions attempting make change same row (one session overwriting changes made other), @ least 1 of transactions wait obtain lock held other transaction. when lock released first transaction, second transaction can obtain lock, , proceed changes; free overwrite changes made other session.
whether things wind mess depends on design of transactions, , qualifies mess.
Comments
Post a Comment