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:

  1. mysql/innodb
  2. several connections @ "same" time
  3. a transaction writing same tables (even more, same queries).
  4. only 1 database
  5. no lock table done @ all
  6. . no nested transactions
  7. no memcache or othe similar system, simple possible.
  8. 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

Popular posts from this blog

apache - Remove .php and add trailing slash in url using htaccess not loading css -

javascript - jQuery show full size image on click -