原子的claim
複数ワーカーが同じ入力ファイルを同時に処理しないよう、処理権の確保を1操作で行うこと。incomingからprocessing/<worker>/へのrenameのほか、FileMode.CreateNewやO_CREAT|O_EXCLによる原子的なファイル作成でも実現できる。
- 概念URI
https://comcomponent.com/knowledge/atomic-claim/- 別名・表記
- claim / Atomic Claim
- 最終確認日
- 2026-08-01
- 機械可読データ
- JSON-LD
この概念が関わる関係
- 受け渡しプロトコルは原子的claimを利用します。受け渡しプロトコルは、複数ワーカーが同じ入力を同時に処理しないよう原子的claimを構成要素として使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- 原子的claimは原子的作成(CreateNew / O_CREAT|O_EXCL)を利用します。renameではなくファイル作成そのもので原子性を確保する場合、原子的claimは.NETのFileMode.CreateNew系やPOSIXのO_CREAT|O_EXCLによる原子的作成でも実現できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
- 原子的claimは二重処理(二重計上・二重送信・更新の消失)を防ぎます。incomingからprocessing/<worker>/へのrenameが成功したワーカーだけを所有者にすることで、複数ワーカーによる同一ファイルの二重処理を防ぐ / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- 原子的claimはExists->Createの二段階チェックに対する本記事の推奨です。Exists->Createの二段階チェックが抱える競合問題に対し、本記事はrenameによる原子的claimを推奨している / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- 原子的claimは二重処理(二重計上・二重送信・更新の消失)を防ぎます。再スキャンで見つかったready候補も、incomingからprocessing/<worker>/へのrenameが成功した側だけが所有者になることで、複数ワーカーの同時処理を防ぐ / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- bundle(連携単位のディレクトリ)は原子的claimを利用します。本体・manifest・補助ファイルをまとめたbundleディレクトリごと1回のrenameでclaimできる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
- full rescan(ディレクトリの全体再走査)は原子的claimより先に行うべきです。ディレクトリ再スキャンでready な候補を洗い出したあとにclaimを試みる、という順序が実務では推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
この概念を扱う記事
一次資料
このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。