title: Is READ COMMITED transactional isolation level implicity when using FOR UPDATE?
body: <p>After scouring the internet for information about Transactional Isolation levels, I understood that Row Locking in MySQL can be achieved by using either <code>SELECT...FOR UPDATE</code> or <code>LOCK IN SHARE MODE</code> and also that, a row locking query must execute after starting the transaction. So I came across some example illustrating the implementation of READ COMMITTED isolation level for two sessions like this:</p>
  
  <pre><code>--session 1
  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
  
  BEGIN TRANSACTION;
  
  SELECT FirstName FROM EmployeeInfo
  WHERE EmpID = 1;
  
  WAITFOR DELAY '00:00:05'  
  
  SELECT FirstName FROM EmployeeInfo
  WHERE EmpID = 1;
  
  ROLLBACK TRANSACTION;
  </code></pre>
  
  <p>The code for session 2 is like so:</p>
  
  <pre><code> --session 2
   UPDATE EmployeeInfo
   SET FirstName = 'Frank'
   WHERE EmpID = 1;
  </code></pre>
  
  <p>In the code sample for session1, the <strong>transaction  Isolation level</strong> and the <strong>beginning</strong> of a transaction are explicit. In a certain blog I read that </p>
  
  <ul>
  <li>UPDATE statements implicitly create READ locks on affected rows in a transaction.
  So does this means that I can safely omit <code>SET TRANSACTION ISOLATION LEVEL READ COMMITTED;</code> from session 1 and still get the same results.In other words how true is the statement <strong>UPDATE statements implicitly create READ locks on affected rows in a transaction.</strong></li>
  </ul>