事务中的ISOLATION级别 [英] ISOLATION levels in Transaction
问题描述
我想知道什么是最好的方式来达到事务的隔离级别？
这是可用的ISOLATION级别的良好链接。 p>
Blockquote如果有人可以解释事务的各种隔离级别，这将是很好的。
更新：说明和更正的说明。
隔离级别仅表示您的交易有多少受其他并发交易影响。隔离级别越高，受影响的程度就越小。
这种努力将在cpu负载，内存负载以及可能的提交延迟中表现出来。此外，在更高的隔离级别中更可能发生写冲突，这可能意味着您必须中止事务并重试整个事务。 （这只影响执行更新或插入的事务，而不影响只执行选择的事务。）
一般来说，经验法则是使用最低级别，应用程序所需的一致性。
Read Committed模式提供的部分事务隔离适用于许多应用程序，并且此模式使用快速简单;然而，它并不足以满足所有情况。执行复杂查询和更新的应用程序可能需要比读提交模式提供的更严格一致的数据库视图。
Serializable模式提供了严格的保证，完全一致的数据库视图。然而，应用程序必须准备在并发更新使得不可能维持串行执行的错觉时重试事务。由于重做复杂事务的成本可能很大，因此只有在更新事务包含足够复杂的逻辑，以致在Read Committed模式下给出错误答案时，才推荐可序列化模式。最常见的是，当一个事务执行几个必须看到数据库相同视图的连续命令时，Serializable模式是必须的。
（ http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html 非常很好。）
I want to know that what is the best way to arrive at the isolation level of the transaction? This is a good link of the available ISOLATION levels.
Blockquote It will be nice if someone can explain the various isolation levels of a transaction
Update: Clarified and corrected explanation.
Isolation levels just indicate how much of your transaction is affected by other concurrent transactions. The higher the isolation level, the less affected it is.
The effort will be made manifest in cpu load, memory load, and perhaps commit latency. In addition, write conflicts can be more likely in higher isolation levels, which may mean that you have to abort your transaction and retry the whole thing. (This only affects transactions that perform updates or inserts, not transactions which only perform selects.)
In general, the rule of thumb is to use the lowest level that gives your application the consistency it needs.
The partial transaction isolation provided by Read Committed mode is adequate for many applications, and this mode is fast and simple to use; however, it is not sufficient for all cases. Applications that do complex queries and updates might require a more rigorously consistent view of the database than Read Committed mode provides.
The Serializable mode provides a rigorous guarantee that each transaction sees a wholly consistent view of the database. However, the application has to be prepared to retry transactions when concurrent updates make it impossible to sustain the illusion of serial execution. Since the cost of redoing complex transactions can be significant, serializable mode is recommended only when updating transactions contain logic sufficiently complex that they might give wrong answers in Read Committed mode. Most commonly, Serializable mode is necessary when a transaction executes several successive commands that must see identical views of the database.
( http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html is very nice. )
这篇关于事务中的ISOLATION级别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
