Difference between read commited and repeatable read

Question

I think the above isolation levels are so alike  Could someone please describe with some nice examples what the main difference is

User · Answer

Simply the answer according to my reading and understanding to this thread and @remus-rusanu answer is based on this simple scenario:

There are two transactions A and B. Transaction B is reading Table X Transaction A is writing in table X Transaction B is reading again in Table X.

ReadUncommitted: Transaction B can read uncommitted data from Transaction A and it could see different rows based on B writing. No lock at all
ReadCommitted: Transaction B can read ONLY committed data from Transaction A and it could see different rows based on COMMITTED only B writing. could we call it Simple Lock?
RepeatableRead: Transaction B will read the same data (rows) whatever Transaction A is doing. But Transaction A can change other rows. Rows level Block
Serialisable: Transaction B will read the same rows as before and Transaction A cannot read or write in the table. Table-level Block
Snapshot: every Transaction has its own copy and they are working on it. Each one has its own view

User · Answer

My observation on initial accepted solution   Under RR  default mysql  - If a tx is open and a SELECT has been fired  another tx can NOT delete any row belonging to previous READ result set until previous tx is committed  in fact delete statement in the new tx will just hang   however the next tx can delete all rows from the table without any trouble  Btw  a next READ in previous tx will still see the old data until it is committed

User · Answer

Please note that  the repeatable in repeatable read regards to a tuple  but not to the entire table  In ANSC isolation levels  phantom read anomaly can occur  which means read a table with the same where clause twice may return different return different result sets  Literally  it s not repeatable

User · Answer

Old question which has an accepted answer already  but I like to think of these two isolation levels in terms of how they change the locking behavior in SQL Server   This might be helpful for those who are debugging deadlocks like I was   READ COMMITTED  default   Shared locks are taken in the SELECT and then released when the SELECT statement completes  This is how the system can guarantee that there are no dirty reads of uncommitted data  Other transactions can still change the underlying rows after your SELECT completes and before your transaction completes   REPEATABLE READ  Shared locks are taken in the SELECT and then released only after the transaction completes   This is how the system can guarantee that the values you read will not change during the transaction  because they remain locked until the transaction finishes

User · Answer

I think this picture can also be useful  it helps me as a reference when I want to quickly remember the differences between isolation levels  thanks to kudvenkat on youtube

User · Answer

Repeatable Read  The state of the database is maintained from the start of the transaction  If you retrieve a value in session1  then update that value in session2  retrieving it again in session1 will return the same results  Reads are repeatable   session1 gt  BEGIN  session1 gt  SELECT firstname FROM names WHERE id   7  Aaron  session2 gt  BEGIN  session2 gt  SELECT firstname FROM names WHERE id   7  Aaron session2 gt  UPDATE names SET firstname    Bob  WHERE id   7  session2 gt  SELECT firstname FROM names WHERE id   7  Bob session2 gt  COMMIT   session1 gt  SELECT firstname FROM names WHERE id   7  Aaron   Read Committed  Within the context of a transaction  you will always retrieve the most recently committed value  If you retrieve a value in session1  update it in session2  then retrieve it in session1again  you will get the value as modified in session2  It reads the last committed row   session1 gt  BEGIN  session1 gt  SELECT firstname FROM names WHERE id   7  Aaron  session2 gt  BEGIN  session2 gt  SELECT firstname FROM names WHERE id   7  Aaron session2 gt  UPDATE names SET firstname    Bob  WHERE id   7  session2 gt  SELECT firstname FROM names WHERE id   7  Bob session2 gt  COMMIT   session1 gt  SELECT firstname FROM names WHERE id   7  Bob   Makes sense

User · Answer

Read committed is an isolation level that guarantees that any data read was committed at the moment is read  It simply restricts the reader from seeing any intermediate  uncommitted   dirty  read  It makes no promise whatsoever that if the transaction re-issues the read  will find the Same data  data is free to change after it was read   Repeatable read is a higher isolation level  that in addition to the guarantees of the read committed level  it also guarantees that any data read cannot change  if the transaction reads the same data again  it will find the previously read data in place  unchanged  and available to read   The next isolation level  serializable  makes an even stronger guarantee  in addition to everything repeatable read guarantees  it also guarantees that no new data can be seen by a subsequent read   Say you have a table T with a column C with one row in it  say it has the value  1   And consider you have a simple task like the following   BEGIN TRANSACTION  SELECT   FROM T  WAITFOR DELAY  00 01 00  SELECT   FROM T  COMMIT    That is a simple task that issue two reads from table T  with a delay of 1 minute between them     under READ COMMITTED  the second SELECT may return any data  A concurrent transaction may update the record  delete it  insert new records  The second select will always see the new data  under REPEATABLE READ the second SELECT is guaranteed to display at least the rows that were returned from the first SELECT unchanged  New rows may be added by a concurrent transaction in that one minute  but the existing rows cannot be deleted nor changed  under SERIALIZABLE reads the second select is guaranteed to see exactly the same rows as the first  No row can change  nor deleted  nor new rows could be inserted by a concurrent transaction    If you follow the logic above you can quickly realize that SERIALIZABLE transactions  while they may make life easy for you  are always completely blocking every possible concurrent operation  since they require that nobody can modify  delete nor insert any row  The default transaction isolation level of the  Net System Transactions scope is serializable  and this usually explains the abysmal performance that results   And finally  there is also the SNAPSHOT isolation level  SNAPSHOT isolation level makes the same guarantees as serializable  but not by requiring that no concurrent transaction can modify the data  Instead  it forces every reader to see its own version of the world  it s own  snapshot    This makes it very easy to program against as well as very scalable as it does not block concurrent updates  However  that benefit comes with a price  extra server resource consumption    Supplemental reads    Isolation Levels in the Database Engine Concurrency Effects Choosing Row Versioning-based Isolation Levels

User · Answer

Trying to explain this doubt with simple diagrams   Read Committed  Here in this isolation level  Transaction T1 will be reading the updated value of the X committed by Transaction T2     Repeatable Read  In this isolation level  Transaction T1 will not consider the changes committed by the Transaction T2

[sql] Difference between "read commited" and "repeatable read"

Examples related to sql

Examples related to sql-server

Examples related to isolation-level