つい先日の話ですが、
「コネクション・プールのDB接続が切断されていた場合、アプリが再接続するように実装するのがクラウドでは当たり前だ。」
みたいな話から、サポート・エンジニア内でチョットした雑談をしたんですが、調べてみると、対応として、
- ConnectRetryCount/RetryInterval, ConnectionTimeoutプロパティ
- ReliableSqlConnectionとか、Pollyなどのフレームワーク。
- spring-retry（Javaの場合）などのフレームワーク
辺りの（、ミッションクリティカルなシステムでは、当たり前といえば当たり前の設計話
が）、ヒットするのですが、
とは言え、ヤハリ、
「業務要件（≒問題領域、ドメイン）が解らない場合は、正確な回答をし辛いな。」
と言う気がしました。
何故
なら、単純な参照系の処理であれば、
問題は少ないですが、更新系の処理の場合、
「トランザクションのリクエストのレスポンスのTCP/IPコネクションがRSTパケットでリセットされたような場合、リトライ処理フレームワークを使用して単純にリトライ処理を実行するダケだと二重登録などが発生するタメ。」
ですね。
このような場合、通常の、業務なら、ConnectRetryCountなど、DB接続部分コンフィグのみの対応で済まして、後は、システム・エラーで落とした方が、設計として無難と思います。
また、コールセンター業務のように、システム・エラー時のSessionクリアで業務続行が出来なくなると、業務に多大な影響を与えるようなケースであれば、先ずは、Sessionをクリアをしないように、「
B層で業務続行可能例外に振り替えるなどの実装」に変える方が、コスパが良い対応が出来る気がします。
それでも、度々、接続が切れて業務に支障が出るようなら、ロング・トランザクション部位から慎重に対応を入れるなど。しかし、
当該アーキテクチャで、トランザクションを維持するような仕組みは、大分前に、既に死んでいますし、2フェーズ・コミットすら最近はあまり聞かなくなったので、分散トランザクション系は難しいと思います。
...とは言え、マイクロサービス・アーキテクチャみたいなモノが隆盛して行くと、そうも言ってられませんが、まぁ、やるとして参照系だけじゃないかな？と。でも、参照系WebAPIがブチブチ切れたらどうするんですかね？[F5]で済めば良いケド、そうじゃない場合、そこにリトライ対応入れるか？みたいな話もありそうです。
...と言う事で、
再々申し上げているように、
マーケティング時のSTPのような話が、
技術選定時や、設計・実装時にもあり、
「ガイドラインやベストプラクティス、ベターユースの類の適用の際は、当該ドメインのセグメントに合わせてフィッティング & テーラリングが重要になる。」
と思います。何でも彼んでも（なんでもかんでも）、十把一絡げに新しい技術を当て込めば良いってモンでもありませんよね。
＜参考＞
トップページ
お知らせ
開発基盤部会
ガイドライン適用の際はフィッティングが重要な件（リトライ実装の例
