本文介绍Neo4j图数据库的事务与锁机制。默认隔离级别为读已提交，写锁自动获取，遍历数据不受保护。锁落在节点或关系上，dense节点建边时锁粒度更细。死锁是可重试的瞬时错误，需固定更新顺序。删除节点需先删关系。

PostgreSQL 的隔离级别从宽松到严格依次为读已提交、可重复读、可串行化，分别防止脏读、不可重复读、幻读和序列化异常。MVCC 通过快照实现隔离，快照记录事务状态而非 LSN。CDC 中，复制槽创建时导出快照，配合 WAL 流确保数据完整，需用可重复读只读事务导入快照。

本文讨论了分布式事务中的两阶段提交（2PC）及其在实际应用中的问题，如协调者故障、网络分区和日志丢失等。介绍了Google的Percolator如何解决这些问题，并探讨了Saga和TCC等其他事务处理模式。最后，分析了现代数据库如Spanner、CockroachDB和TiDB的不同解决方案，强调了一致性、可用性和性能之间的权衡。

本文介绍WiredTiger存储引擎中Connection、Session、Cursor三层句柄的生命周期与线程模型。Connection独占数据库实例，Session单线程且同时仅持有一个事务，Cursor由Session拥有并共享事务上下文。文章强调多线程应共享Connection但各自持有Session，并澄清常见误解，为后续Cache与Eviction章节铺垫。

本文介绍WiredTiger存储引擎的时间戳与快照机制。核心概念包括：应用时间戳由上层控制，执行时间是墙上时钟；active time window由oldest、stable、pinned界定可读与可丢弃历史；快照通过max/min/并发事务ID列表决定可见性；默认snapshot隔离，prepared事务有特殊边界。文章强调时间戳与快照共同支撑MongoDB的MVCC实现。

本文介绍SQLite事务的三种BEGIN模式：DEFERRED推迟取锁，IMMEDIATE立即获取RESERVED锁，EXCLUSIVE在WAL模式下与IMMEDIATE等价。SQLite通过写串行化实现SERIALIZABLE隔离，单写者模型天然避免write skew异象。WAL模式下快照过期会返回SQLITE_BUSY_SNAPSHOT，需回滚重试。COMMIT落盘时机由日志模式决定。

本文介绍SQLite的ATTACH DATABASE功能，允许一个连接同时操作多个数据库文件。跨库事务在rollback journal模式下通过super-journal机制保证原子性，但WAL模式下会退化为各文件独立原子。锁按文件独立跟踪，跨库写需在所有文件上获取EXCLUSIVE锁。事务进行中的库无法DETACH。同名表省略前缀时取最早挂载的库。

FoundationDB 采用控制面与数据面分离的架构，支持独立扩展。事务处理流程包括获取读版本、提交、冲突检测及日志持久化。本文为系列第一篇，介绍了角色分工及事务路径。

本文讨论了FoundationDB的写事务提交过程，强调提交成功与数据可见性之间的区别。提交由Commit Proxy协调，涉及Sequencer、Resolver和TLog。客户端在提交后依赖TLog的耐久性，但Storage Server的可读性可能会延迟。文章还探讨了批处理、冲突检测及与TiKV的对比，指出了系统设计选择和潜在的工程挑战。

本文讨论了FoundationDB的事务处理机制，重点介绍了@transactional函数的使用、冲突检测、自动重试及5秒事务限制。事务在客户端缓冲写入，提交时检查读写冲突，读过的key会影响冲突范围。事务需在5秒内完成，超时将导致失败。文章强调了幂等性的重要性，以确保重试时结果的一致性。

TiKV 的悲观锁默认使用内存路径以减少加锁延迟，但在非计划的 Leader 切换时可能会丢失锁。锁的 TTL 动态调整，长事务依赖心跳续期。死锁检测采用集中式方案，Leader 切换时清空历史依赖，存在漏检风险。TiKV 的锁机制与传统数据库相似，需纠正对其“无锁”的误解。

本文探讨了TiKV如何实现Percolator论文中的data/lock/write模型，分析了TiKV在编码、Prewrite/Commit过程中的调整，包括Rollback记录、短值优化和Lock类型写记录。TiKV将Prewrite的原子性单位从单行事务改为Region的Raft提交，并通过Async Commit和1PC优化减少延迟，满足在线事务的性能需求，展示了TiKV在生产环境中的应用与论文模型的差异。

本文讨论了RocksDB的事务机制，包括悲观锁和乐观事务的实现。WriteBatch确保批内原子性，但不处理并发冲突。TransactionDB使用悲观锁进行冲突检测，而OptimisticTransactionDB在提交时检查冲突。WritePrepared优化了两阶段提交的路径。TiKV在分布式层实现事务，RocksDB事务API为本地引擎提供能力，适用于低冲突和高冲突的事务处理场景。