Recently, I’m starting to put eyes on the database implementation. One of the articles I have read is When is “ACID” ACID? Rarely
To understand the article, I checked the definitions of different isolation levels, just keep a note here:
RC: read committed: 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. 
RR: 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. 
S: serializability: the outcome of executing a set of transactions should be equivalent to some serial execution of those transactions. 
SI: snapshot isolation: In databases, and transaction processing (transaction management), snapshot isolation is a guarantee that all reads made in a transaction will see a consistent snapshot of the database (in practice it reads the last committed values that existed at the time it started), and the transaction itself will successfully commit only if no updates it has made conflict with any concurrent updates made since that snapshot. 
CS: cursor stability: Like levels RR and RS, level Cursor Stability (CS) ensures that any row that was changed (or a row that is currently locked with an UPDATE row lock) by another activation group using a different commitment definition cannot be read until it is committed. 
CR: consistent read: same with SI????