Kyle Kingsbury via discuss <[email protected]> writes: >> So I have always thought of REPEATABLE READ to be "repeatable" for read-only >> transactions spanning multiple selects. > > That property does seem to hold! I can't seem to find any actual > documentation to this effect though--you're the first person who's > suggested it. Any chance you've got a source handy?
I don't think this is based on any specific source. Rather, it's starting from how InnoDB takes read/write locks and thinking through what this means in terms of behaviour: READ COMMITTED - no read locks, only write locks, new snapshot each statement. REPEATABLE READ - no read locks, but keep the snapshot (for SELECTs) over the transaction. SERIALIZABLE - both read and write locks. For me, this is a good starting point for understanding how things need to work, together with the requirement that update transactions can be replayed in sequence and get identical data (to support replication). But this ignores many tricky details, and is probably too crude to be of much use at the level of a thorough test like yours. - Kristian. _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
