| Bug #64159 | isolation levels "repeatable read" and "serializable" runs like read committed | ||
|---|---|---|---|
| Submitted: | 29 Jan 2012 20:45 | Modified: | 30 Jan 2012 13:35 |
| Reporter: | jose luis martin | Email Updates: | |
| Status: | Not a Bug | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
| Version: | 5.5.20 | OS: | Windows (windows 7) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | Isolation level | ||
[29 Jan 2012 20:48]
Valeriy Kravchuk
Are you 100% sure your tables are created as InnoDB? Please, send also complete test case, exact statements to copy/paste in both sessions.
[30 Jan 2012 12:49]
jose luis martin
Exactly, this problem does not exist in InnoDb. Excuse me.

Description: server: MySQL 5.5.20 client: command line client SO: windows 7 professional service pack 1 A transaction with isolation level "repeatable read" or "serializable" works like a transaction with isolation level "read committed": a SELECT stament see all the changes (UPDATE, INSERT, DELETE) made by any other committed transaction How to repeat: open two "command line client" sessions ("session A" and "session B") in both sessions: SET AUTOCOMMIT=0; in "session B": SET session TRANSACTION ISOLATION LEVEL repeatable read (or serializable) in "session A": execute an UPDATE, INSERT or DELETE over tableA in "session B": execute a SELECT * FROM tableA Suggested fix: apply the standard