我想知道达到事务隔离级别的最佳方法是什么? 这是可用隔离级别的一个很好的链接。
Blockquote 如果有人可以解释事务的各种隔离级别,那就太好了
我想知道达到事务隔离级别的最佳方法是什么? 这是可用隔离级别的一个很好的链接。
Blockquote 如果有人可以解释事务的各种隔离级别,那就太好了
更新:澄清和更正的解释。
隔离级别仅表明您的事务有多少受到其他并发事务的影响。隔离级别越高,受影响越小。
这些努力将体现在 cpu 负载、内存负载以及可能的提交延迟上。此外,在更高的隔离级别下,写冲突更有可能发生,这可能意味着您必须中止事务并重试整个事情。(这只影响执行更新或插入的事务,而不影响只执行选择的事务。)
一般来说,经验法则是使用为您的应用程序提供所需一致性的最低级别。
Read Committed 模式提供的部分事务隔离对于很多应用来说已经足够了,而且这种模式使用起来又快又简单;但是,它并不适用于所有情况。执行复杂查询和更新的应用程序可能需要比 Read Committed 模式提供的更严格一致的数据库视图。
Serializable 模式提供了严格的保证,即每个事务都看到一个完全一致的数据库视图。但是,当并发更新无法维持串行执行的错觉时,应用程序必须准备好重试事务。由于重做复杂事务的成本可能很高,因此仅当更新事务包含足够复杂的逻辑以致它们可能在已提交读模式下给出错误答案时,才建议使用可序列化模式。最常见的是,当事务执行多个必须看到相同数据库视图的连续命令时,Serializable 模式是必需的。
(http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html非常好。)
如果您不确定隔离级别的差异,请坚持使用默认值。更改级别可能会产生特殊的副作用。99% 的应用程序都可以使用默认设置。
我认为默认值因每个 JDBC 驱动程序而异,尽管像 JPA 这样的一些框架可能会强制执行它,但我不记得了。最常见的默认值是 read_committed,因为它在事务安全性和并发性之间提供了最佳的通用平衡。如果选择不同的隔离级别,则会牺牲安全性或并发性,并且必须注意妥协。
到底是什么问题?!
隔离级别定义了 DBMS 使用的锁类型和锁粒度。锁定在 DBMS 的上下文中是必不可少的,因为事务是由潜在的许多用户同时执行的。更高的事务隔离性——例如 SERIALIZABLE——更安全——您可以潜在地消除脏读和幻像更新——但由于序列化事务限制了并发性并因此排除了可伸缩性,因此会受到惩罚。
该怎么办?构建应用程序,使得逻辑通过在绝对需要时明智地使用序列化事务来限制“坏数据”的可能性,但不会不必要地阻碍并发性。
事务隔离级别是关于解决并发事务中的数据读取问题(当我们在一个事务中读取相同的数据而另一个事务同时更改时)。
有 4 个隔离级别。每个解决 1 个相关问题 + 之前所有级别的问题:
# | 隔离级别 | 待解决的问题 | 问题描述 |
---|---|---|---|
1 | 读未提交 | 丢失更新 | 只有最后一个并发事务会影响读取数据。其他事务的影响丢失 |
2 | 读已提交 | 脏读 | 读取的数据被事务更改,然后回滚 |
3 | 可重复读取 | 不可重复读 | 第二次读取相同数据的结果与第一次读取不同,因为数据在读取之间被另一个事务更改 |
4 | 序列化 | 幻读 | 通过相同参数选择的第二个数据与第一个不同,因为数据在读取之间被另一个事务更改 |