Transactions 事务、锁、隔离级别

我对标题中的主题有几个问题。首先，假设我们使用JDBC，这里有两个事务T1和T2。在T1中，我们在一个特定的行上执行select语句。然后，我们对该行执行update。在事务T2中，我们在同一行上执行select语句

以下是问题：

1） 事务T1何时获取所述行上的锁？我假设它发生在select语句执行期间

2） 事务T1持有锁的时间有多长？它是在提交/回滚事务之前保持它，还是在提交/回滚事务之前释放锁

3） 隔离级别是否控制所使用的锁的类型？例如：

a） 如果我们在事务T2上使用readcommitted隔离级别，这是否意味着T2将对select语句使用共享读锁，以便在T1已更新行的情况下，T2将无法访问该行（避免脏读），并且在T1未更新行的情况下，T2将具有该行的读访问权限

b） 如果我们在事务T2上使用readuncommitted隔离级别，这是否意味着T2将不对select语句使用锁，这样即使T1修改它也可以读取数据（允许脏读）

所以，最让我困扰的问题是谁来决定应用哪种类型的锁？是事务的隔离级别，还是有其他方法

4） 如果问题3的答案是肯定的（隔离级别控制使用什么锁），那么如果我们在mysql数据库上使用jdbc，并在共享模式构造中使用select进行更新或select lock，会发生什么情况？我记得第一个是独占锁，第二个是共享读锁。它将如何反映我们的事务隔离级别

5） 在可重复读取隔离级别的情况下，会获得什么类型的锁？假设我们的T2（具有可重复读取隔离级别）在同一行上有两个select语句，而T1与之前相同。首先在T2中执行一个select语句，然后执行并提交T1，然后在T2之后执行第二个select语句。这种情况可能吗？如果事务在提交/回滚之前一直持有锁，那么我假设在T2完成之前T1将无法获得用于更新的独占锁

编辑：还有一个问题：

6） 在多版本并发控制系统中，当我们设置可串行化的隔离级别时，试图更新由另一个事务B更新的某一行（B在A启动后更新了该行）的事务A将回滚。我想问的是，这和乐观锁定场景中发生的情况不一样吗

---

提前谢谢。

你的问题很好。了解获得的锁类型可以深入了解DBMS。在SQL Server中，在所有隔离级别（未提交读取、已提交读取（默认）、可重复读取、可序列化）下，为写入操作获取独占锁

无论隔离级别如何，事务结束时都会释放独占锁

隔离级别之间的差异是指获取/释放共享（读取）锁的方式

在读取未提交的隔离级别下，不获取共享锁。在此隔离级别下，可能会出现称为“脏读”的并发问题

在读取提交隔离级别下，为相关记录获取共享锁。当当前指令结束时，将释放共享锁。此隔离级别可防止“脏读”，但由于记录可由其他并发事务更新，因此可能会发生“不可重复读取”或“幻象读取”

在可重复读取隔离级别下，为事务持续时间获取共享锁。防止“脏读”和“不可重复读”，但仍可能发生“幻象读”

---

在隔离级别下，将为事务持续时间获取范围内的共享锁。上面提到的并发问题都没有出现，但性能大大降低，存在死锁发生的风险。

这是很多问题。。。答案取决于使用的特定DB/版本。。。那么我们谈论的数据库是什么呢？好吧，假设它是mysql 5.5:）好吧-这还不够，因为mysql可以与不同的存储引擎一起使用，而不同的存储引擎在事务方面的表现也非常不同，那么：什么存储引擎呢？听着，我可以说InnoDB，但我认为它使用多版本并发控制，我的问题更多的是关于经典的基于锁的并发控制。但好吧，假设它是InnoDB存储引擎。我甚至还有一个关于mvcc及其与基于乐观的锁定的关系的问题：）对于一些一般观点，请参见-尽管我认为这个问题属于serverfault.com