続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi

三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（

[matarillo]

前回もブコメしたが遷移する状態にidentifierがあるとべんり。gitならばコミットのハッシュだし、データベース更新だとタイムスタンプ列が使われたりもする。過去の自分との楽観的同時実行制御に似ているのだと思う

[kuenishi]

Riak CSではこの手のIDにUUIDを使っていますね。まとめて何かやるってときは複数のオブジェクトに状態を持たせて状態毎にロジック決めて解決

[ihag]

作ったリソースにバージョン的な物を付けられれば、パターン3のAppendは楽観的ロックでもいけそう/僕的にはDBのロック待ちでエラー応答のタイミングが揃い、リトライでDoSを始めるRESTクライアントが最高にロックだった

[nishidy]

何回読んでも面白い

[hiroyukim]

これに関する資料とか本とかないかな

[kasumani]

続・リトライと冪等性のデザインパターン - リトライはいつ成功するか リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 Tags: feedly, ifttt, r

[masa_matya]

冪等性確保において、incrementやappendは難しい。createに置き換える事で担保可能になる場合がある。

[zaki_taka4]

待ってました。

[a_suenami]

おもしろくなってきた。

[ruicc]

appendやincrementの冪等性

[warufuzaketaichi]

「単調増加する整数」をキチンと提供できるサーバって結構難しい感ございます。

[hatajoe]

おもしろい！！

[airj12]

DBMSの下回りのやり口っぽい(知らんけど

[ymm1x]

続編だ。トランザクションが最終奥義なの？

[masudaK]

「三度の飯よりエラー処理」

[soma28]

続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi

[sugyan]

続編

[noonworks]

すごく面白い……冪等性を前提にするプロトコル設計、書籍とかあるのかな、それとも経験からのノウハウなのかな？

[teppeis]

バルクでまとめる話

[trashtoy]

“操作ログとリクエストIDでUPDATEを冪等にする” 前回の記事の後に自分が悶々と考えていたの、たぶんコレだ

[joker1007]

盛り上がってきた！

[nobusue]

これは必読

[tumo300-500]

続ブクマ

[kwry]

]

[sonots]

徐々に盛り上がってきた

[tagomoris]

まだまだこれからという感じだ

[kazuhooku]

徐々に面白くなってきた