God's in his heaven.
All's right with the world.

Question

To avoid deadlocks, we switched from ReadCommittedSnapshot isolation to SnapShot isolation for a SQL Server database at the database level and transaction level in the client code. Now, when two users perform concurrent operations on the database through the client, one of the clients get this error:

“Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to access table ‘dbo.cust_table’ directly or indirectly in database ‘cust_database’ to update, delete, or insert the row that has been modified or deleted by another transaction. Retry the transaction or change the isolation level for the update/delete statement.”

What can we do to avoid deadlocks and update conflicts at the same time?

(The same code with Oracle database and Oracle client works without any issues with the default Read Committed Snapshot isolation level)

- SusmithaP

Isolation levels are a rare subject in MySQL literature. The documentation provides a terse description and focuses mainly on locking issues, but does not discuss the semantics of each isolation level. This is not only a problem that affects MySQL documentation but also the SQL standard itself.

Both the lack of documentation and the absence of a deeper description of the expected behavior in the SQL standard make isolation levels a topic that is more assumed than known by database administrators and developers. In this blog post, I aim to help you understand how the default isolation level in MySQL works and show you some surprising facts about it.

But first let’s see how isolation levels are described in the standard: “The transaction isolation level of a SQL-transaction defines the degree to which the operations on SQL-data, or schemas in that SQL-transaction are affected by the effects of and can affect operations on SQL-data or schemas in concurrent SQL-transactions”. To put it in plain words, isolation levels define how concurrent transactions interact while modifying data.

MySQL uses Repeatable-read as the default level. In the standard, this level forbids dirty reads (non committed data) and non repeatable reads (executing the same query twice should return the same values) and allows phantom reads (new rows are visible). But MySQL implements it in a different way. Let’s see how it is implemented with some examples.

This article is part of a series. You do not have to read them in order but I will be referring to topics and explanations in previous articles:

1. Implementing Your Own Transactions with MVCC
2. SQL Transaction Isolation Levels Explained
3. Implementing Repeatable Read and Serializable Transaction Isolation

This article is part of a series. You do not have to read them in order but I will be referring to topics and explanations in previous articles:

1. Implementing Your Own Transactions With MVCC
2. SQL Transaction Isolation Levels Explained
3. Implementing Repeatable Read and Serializable Transaction Isolation

This article is part of a series. You do not have to read them in order but I will be referring to topics and explanations in previous articles:

1. Implementing Your Own Transactions With MVCC
2. SQL Transaction Isolation Levels Explained
3. Implementing Repeatable Read and Serializable Transaction Isolation

一、什么是SPV

SPV是 “Simplified Payment Verification”（简单支付验证） 的缩写。中本聪论文简要地提及了这一概念，指出：不运行完全节点也可验证支付，用户只需要保存所有的block header就可以了。用户虽然不能自己验证交易，但如果能够从区块链的某处找到相符的交易，他就可以知道网络已经认可了这笔交易，而且得到了网络的多少个确认。

按照中本聪的原文，这里有个细节需要注意，SPV指的是“支付验证“，而不是“交易验证”。这两种验证有很大区别。
"交易验证”非常复杂，涉及到验证是否有足够余额可供支出、是否存在双花、脚本能否通过等等，通常由运行完全节点的矿工来完成。
“支付验证”则比较简单，只判断用于“支付”的那笔交易是否已经被验证过，并得到了多少的算力保护（多少确认数）。

考虑这样一种情况，A收到来自B的一个通知，B声称他已经从某某账户中汇款一定数额的钱给了A。去中心方式下，没有任何人能证明B的可靠。接到这一通知，A如何能判断B所说的是真的呢？
在比特币系统中，这一通知是以一个固定格式的“交易"来实现的，该交易中包含B的汇款账户、B的签名、汇给A的金额以及A的地址。
如果A想本人亲自验证这笔交易，首先，A要遍历区块链账本，定位到B的账户上，这样才能查看B所给的账户上是否曾经有足够的金额；接下来，A要遍历后续的所有账本，看B是否已经支出了这个账户上的钱给别人(是否存在双花欺骗）；然后还要验证脚本来判断B是否拥有该账户的支配权。这一过程要求A必须得到完整的区块链才行。

但是，如果A只想知道这笔支付是否已经得到了验证（如果验证了就发货），他可以依赖比特币系统来快速验证。即，检查发生此项支付的那笔交易是否已经收录于区块链中，并得到了多少个确认。

原文作者：中本聪（Satoshi Nakamoto）

作者邮箱：Satoshin@gmx.com

执行翻译：8btc.com  巴比特 QQagent

[摘要]：本文提出了一种完全通过点对点技术实现的电子现金系统，它使得在线支付能够直接由一方发起并支付给另外一方，中间不需要通过任何的金融机构。虽然数字签名（Digital signatures）部分解决了这个问题，但是如果仍然需要第三方的支持才能防止双重支付（double-spending）的话，那么这种系统也就失去了存在的价值。我们(we)在此提出一种解决方案，使现金系统在点对点的环境下运行，并防止双重支付问题。该网络通过随机散列（hashing）对全部交易加上时间戳（timestamps），将它们合并入一个不断延伸的基于随机散列的工作量证明（proof-of-work）的链条作为交易记录，除非重新完成全部的工作量证明，形成的交易记录将不可更改。最长的链条不仅将作为被观察到的事件序列（sequence）的证明，而且被看做是来自CPU计算能力最大的池（pool）。只要大多数的CPU计算能力都没有打算合作起来对全网进行攻击，那么诚实的节点将会生成最长的、超过攻击者的链条。这个系统本身需要的基础设施非常少。信息尽最大努力在全网传播即可，节点(nodes)可以随时离开和重新加入网络，并将最长的工作量证明链条作为在该节点离线期间发生的交易的证明。

Summary

The UnhandledExceptionFilter function is called when no exception handler is defined to handle the exception that is raised. The function typically passes the exception up to the Ntdll.dll file, which catches and tries to handle it.

In some scenarios in which a memory snapshot of the process exists, you can see that the thread that holds the lock points to a thread that calls the UnhandledExceptionFilter function. In those cases, you can follow the steps in this article to identify the DLL that caused the exception.

CAP理论及BASE理论

分布式系统的CAP理论

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP

本文是关于大学时一些常见的数据结构、算法和知识点的总结。其实与其说工作中会用到，不如说面试时被面到的可能性更大一些。不过其中一些特定领域的算法，像银行家算法，BAT的面试中我也还没有遇到过。适当地回顾大学时学到的一些知识点，也许能给自己带来一些快乐吧，一种仅存在于回忆中的快乐。