【FoundationDB 内核】Client API 与事务模型：冲突范围、自动重试与 5 秒窗口
钉住 FoundationDB 客户端事务契约：读写缓冲、冲突范围、@transactional 自动重试，以及 5 秒上限如何约束应用设计——机制证明留给第 8–9 篇。
occ 标签归档
共 6 篇文章 · 返回首页
【FoundationDB 内核】Resolver 与 OCC：冲突范围、窗口与自动重试
拆解 FoundationDB Resolver 如何用 read/write conflict ranges 做乐观并发控制：冲突窗口落在 read version 与 commit version 之间，客户端自动重试；并与 TiKV Percolator 快照隔离对照机制差异，不写无实测性能结论。
【FoundationDB 内核】严格可串行化与 5 秒限制：实时顺序与恢复有界性
说明 FoundationDB 如何用 Sequencer 版本把 OCC+MVCC 提升到严格可串行化，区分 serialization order 与实时顺序；论证 5 秒事务上限如何约束冲突窗口与恢复日志量，并点明高冲突下的开放问题。
【FoundationDB 内核】Unbundled · OCC · TLog · Redwood · Simulation
补齐 FoundationDB 选型叙事与生产内核之间的一层：拆解 Proxy、Sequencer、Resolver、TLog、Storage Server 的 Unbundled 写路径，严格可串行化、Redwood 与确定性模拟，并以 Record Layer 和 TiKV/etcd 对照收束。
【RocksDB 内核机制】事务与 OptimisticTransactionDB：WritePrepared 边界
对照 WriteBatch 原子性与 Snapshot MVCC，拆解 TransactionDB 悲观锁、OptimisticTransactionDB 提交时冲突检测、WritePrepared 的 prepare/commit 与 CommitCache 边界；TiKV 分布式事务仅作 B 级前瞻，不替代 Percolator 正文。
【数据库前沿】【数据库研究前沿】Iceberg vs Hudi vs Delta：湖仓表格式的事务边界与选型
把 Apache Iceberg、Apache Hudi、Delta Lake 放在同一张表上比较：metadata layout、snapshot isolation、多写者 OCC 协议、schema 与 partition evolution，最后给出 iceberg vs hudi 选型矩阵与对象存储上的事务边界。