我正在研究SQL，需要知道某个事务方案是否可序列化。我理解确定这一点的方法是制作一个以事务作为节点和节点之间的方向的图，如果该图是循环的，则该方案不可序列化。但这是什么意思以及什么决定了图中是否存在从一笔交易到另一笔交易的有向边？在这种情况下，序列化与将对象写入磁盘的序列化类型相同吗？
感谢您的任何见解
事务序列化与对象序列化无关。可序列化事务隔离级别在完全实现后，可确保任何并发可序列化事务集的行为与some串行（一次一个）执行顺序——就好像事务一次运行一个一样。这意味着，如果您可以证明数据库事务在单独运行时会做正确的事情，那么它在任何可序列化事务的组合中都会做正确的事情，或者会因序列化失败而回滚，以便可以重试从头开始。
可通过多种方式强制执行可序列化事务隔离。最常见的方案是严格两阶段锁定（S2PL）。这个问题非常常见，以至于您经常会看到 SO 上的答案，这些答案仅根据这种技术来讨论问题。还有乐观并发控制 (OCC)、可序列化快照隔离 (SSI) 等。
9.1 之前的 PostgreSQL 版本、某些配置中的 MS SQL Server 以及所有版本的 Oracle 实际上并不提供可序列化事务。他们让你要求它们，但实际上提供快照隔离。从 9.1 开始使用 PostgreSQL 版本SSI http://wiki.postgresql.org/wiki/SSI当请求可序列化事务隔离时。
不可能彻底讨论这些技术在 SO 答案中如何工作，但总结一下上面提到的技术：
在 S2PL 下，事务中的每次写入都会获取一个不能与任何内容共享的锁，而事务中的每次读取都会获取一个可以与其他读取共享但不能与写入共享的锁。读锁需要覆盖扫描索引中的“间隙”。锁定将一直保留到事务结束，并随着事务的工作对其他事务可见而自动释放。如果阻塞造成循环，则称为“死锁”，循环中涉及的事务之一将被回滚。
在 OCC 下，事务会跟踪它所使用的数据，而不锁定它。当请求事务提交时，事务检查是否有任何其他事务修改了其任何数据并提交。如果是这样，提交请求将失败并且工作将回滚。
在 SSI 下，写入会互相阻塞，但读取不会阻塞写入，写入也不会阻塞读取。跟踪读写依赖关系以寻找可见性模式，这将按照明显的执行顺序创建循环。如果发现“危险结构”，这意味着表面执行顺序中的循环是可能的，则回滚可能的循环中涉及的事务之一。与 S2PL 相比，它更像 OCC，但在较高争用情况下没有那么多回滚。
全面披露：我与 Dan R.K. MIT 的移植，用于在 PostgreSQL 9.1 中实现新的基于 SSI 的可序列化事务。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
