Miniposts
2026/03/11
論文を読んだ。
https://www.vldb.org/cidrdb/papers/2026/p9-stonebraker.pdf (opens in a new tab)
Consistency and Correctness in Data-Oriented Workflow Systems (CIDR '26)
Stonebraker 御大のSagaに関する論文。 ワークフローシステム・・・というか単一の巨大なトランザクションを諸々の事情（途中で人が介入するとか、外部APIを呼び出すとか、現実世界で不可逆な操作が発生するとか）によって複数のワークフローに分割したシステムでは、補償処理が重要で、伝統的なトランザクションのAbort/Rollbackの実装はあまり役に立たない。 いわゆるSaga的なデザインパターンが支持されていてRDBMSのトランザクションが下火になるのもこのあたりの事情があるが、しかしSagaは書くのがしんどい。そこで、DBOSにタイムトラベル機能を追加することで、ワークフローに任意の時点まで巻きもどってリトライする機能を与えよう・・・という論文。
アプローチはなんだかちょっと違う気がするが、任意の（コミット済みの）トランザクションが一発でRevertできる関数が提供できれば、世の中のアプリケーションは結構救われるのではという感覚はわかる。
2026/03/02
DEIM で論文を発表した。
- https://pub.confit.atlas.jp/ja/event/deim2026/presentation/4E-02 (opens in a new tab)
- https://research.lycorp.co.jp/jp/publications/2522 (opens in a new tab)
以前書いた anomalyに関する記事へのアンサーというか、自分がぼんやりと考えていたことを論文にまとめたもの。 個人的に、トランザクション処理のなかでも concurrency control はもうアプリケーションユーザを抜きにして議論することは不可能なトピックになっており、古典的な「強い一貫性を提供すればユーザは何も気にしなくてOK!!」という世界観を維持するのはかなり厳しいと思っている。
アプリケーションユーザが concurrency control に関与することを前提とするならば、そもそも isolation level は何がいいんだっけ（serializableはtoo muchなのでは）という話からやり直しになるし、弱い一貫性で役に立つシステムやデザインパターンを構築していくことが大事だ。
なんてことは業務でシステムを構築している人はみんなわかっていて、それでも辛酸を嘗めきったからこそ後進のために分散トランザクションに戻ってきているのだろう。 だが私は若手の時代にずっとconcurrency controlをやってきていて、それが理解できていなかった。