Goでconnection lostをどう処理するか?
現在人気のある sql パッケージを少し調べてみたところ、connection lostが発生した際に即座にエラーを出してくれるような機能がほとんど存在しないことに気づいた。例えば nodejs の mysql では、connection.on(‘error’) を使ってエラーを監視できる。
しかし golang(少なくともいくつかの人気のあるパッケージ)では、そういった機能がない。もう少し踏み込んで調べてみれば、その理由も理解できなくはない。
The sql package creates and frees connections automatically; it also maintains a free pool of idle connections. If the database has a concept of per-connection state, such state can be reliably observed within a transaction (Tx) or connection (Conn). Once DB.Begin is called, the returned Tx is bound to a single connection. Once Commit or Rollback is called on the transaction, that transaction’s connection is returned to DB’s idle connection pool. The pool size can be controlled with SetMaxIdleConns.
簡単に言うと、sql.Open を呼び出した時点では実際にはconnectionは確立されず、内部でconnection poolが維持され、必要になったときに初めて接続を試みる仕様になっている。つまり、Queryを実行している最中にネットワークの問題でconnection lostが発生した場合、database/sql が水面下で自動的にretryを試みてくれるわけだ。
実のところ、これは良いことでもあって、自分でリトライのロジックを書かずに済む。だが、queryを発行して初めてconnection lostだったと知るのではなく、それ以前にアプリケーション全体でその事態を把握しておきたい場合もある。僕としては、その前にアプリケーション側で検知したいのだ。
もし似たようなことを実現したいなら、低層の Dialer ロジックを書き換えて、network が切断されたときにプログラムへ即座に通知できるようにする必要がある。
関連記事
- 測定が目標になるとき:窓税からPull Request数まで かつて僕は小さなツールを自作し、四半期で自分がどれだけPRに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計して、上司にアウトプットを証明しようとしたことがある。上司は淡々と、評価はアウトプットだけで見るものではないと言った。数年後、僕はようやく理解した――測定が目標になるとき、それはもはや良い測定ではなくなるのだ。英国の窓税、ハノイのネズミ駆除の報奨金から、現代のPR数による開発者評価に至るまで、そのメカニズムはまったく同じだ。
- Cloudflare Images を画像ストレージ・変換ソリューションとして使う ウェブページに画像を1枚置くのはフロントエンドにとって最も簡単なことだが、リサイズや各種フォーマットの生成、さらにはトラフィックの負荷に耐えることまで完璧にやろうとすると、実際には一つの包括的なソリューションが必要になる。僕はその後、すべて Cloudflare Images に任せるようになり、オリジナル画像1枚だけを渡すようにしている。
- もう AWS Access Key を使うのはやめよう Access Key は AWS において見落とされがちなセキュリティリスクだ。OIDC と IAM Role を組み合わせることで、GitHub Actions にシークレットを一切保持させることなく、安全に AWS リソースを操作できるようにする。
- データベース主キー:AUTO_INCREMENT、UUID、そしてUUIDv7 バックエンド開発で度々直面する主キーの決定。auto incrementを使うべきか、それともUUIDか?衝突への懸念は?UUIDv7とcreated_at + インデックスの性能差はどれほどか?実際に2,000万件のデータで検証したベンチマークと設計上の意思決定を解説する。