MongoDB 在4.0的时候已经开始支持了多文档的 ACID 和隔离，看上去好像对比传统数据库并没有什么值得称颂，但实际上着对于NOSQL的MONGODB是非常有意义的。
先用一个图来表达一下 3.6 和 4.0 在document事务上的不同，还是根据一贯的做法，先实践，在理论。
图中我们想几个问题，3.6 的两个update 如果有一个失败了，会影响另一个update的操作吗，3.6 和 4.0 的操作中，4.0在commit之前我们能否看到已经update的数据，但没有commit
我们在一台mongo database 4.0 社区版的服务器上
1 建立一个 test database
2 通过JS 来生成两个一样的临时数据collection
下面是一段python 完成多文档插入的事务，简易代码
下面我们返回来看看mongodb 4.0提供的多文档事务到底是怎样的来龙去脉。
1 多文档事务，必须建立在复制集的基础上，实际上我也试了，在单机mongodb上是无法完成多文档事务的。（会报错）
2 多文档事务不能用于sharding 集群 （想想都明白为什么不能）
3 仅在wiredTiger 数据引擎支持
4 进行操作时，collection必须已经存在
5 对collection的创建和删除操作，不能再事务中出现
6 对INDEX的创建，删除操作不可以在事务中出现
7 仅仅支持CRUD 操作，其他操作不能再事务中出现
8 仅仅对用户级别的collection 可以操作，系统级别的collection 或db 是不能操作的
9 对事务的大小的限制在 16MB
10 对事务的操作整体不允许超过60秒
11 虽然是事务，但也要尽快的操作完成，否则WireTiger中使用快照来操作维护事务，会造成大量的内存的使用不被释放。
12 事务不能再会话外运行（session）
13 一个session 只能一次运行一个事务，但可以运行多个session 并行运行事务
那下面我们做一个相关的例子，看看isolation是否在MONGODB中存在（查出两条的原因是因为我之前插入过一次数据）
首先整体操作是OK 的
下面我们清理一下数据，将已经插入的数据清空，然后分批的执行事务，但不commit, 来验证一下隔离的问题是否在MONGODB 中生效
在commit 后，相关的信息才能在其他的session中看到 （这就是传统数据库的 RC）
那既然有事务，就会有冲突，在不同的session中修改同一个数据，
自然就报错了。
通过错误可以看到，同时有两个修改同样记录的操作，后者（根据时间），会被自动kill 掉。
session.getDatabase("test").test.find({name:'timenocc'})WriteCommandError({
"errorLabels" : [
"TransientTransactionError"
],
"operationTime" : Timestamp(1587628382, 1),
"ok" : 0,
"errmsg" : "WriteConflict",
"code" : 112,
"codeName" : "WriteConflict",
"$clusterTime" : {
"clusterTime" : Timestamp(1587628382, 1),
"signature" : {
"hash" : BinData(0,"MIsoLQSNFGymhCFZrxcJj/OhuGQ="),
"keyId" : NumberLong("6818778345002500099")
到目前总结一下MONGODB 的事务
1 基本达到了传统数据库的RC级别的事务操作
2 可以进行ISOLATION RC 级别的事务隔离性
3 对多事务中的冲突可以检测，并根据事务的先后，将后来的事务终止，并报错
最后提一下Retryable Writes，这是一个在3.6引入的由于网络问题，造成写失效的补救措施，他会让MONGODB 在重试一次写，前提也是必须是 集群或分片。
这里如果使用事务的情况下，则不管这个Retryable Writes 是开还是关，事务都会在操作失败的时候，进行一次 Retryable Writes.
曾经听说一些关于MONGODB的话，他发展不起来，有局限性，其实到时觉得与其diss ,不如打开心门，迎接变化，就算diss 也先了解以后再说。
