DBIとforkの関係 - heboi blog
実際ググれば正解はいっぱい出てくるしここに自分もコメントで書いてたりしていまさら書く必要もないかなと思ってたけど一応自分のブログでもまとめておくということで。 一般的な解 DBIx::ConnectorとかDBIx::Handler経由でかならず$dbhを取得してからDBIを使う。 もしくはfork-safeなORM(DBIx::Class, DBIx::Skinny, Teng)を使う。 DBIを直接使っている場合 一般的なコネクションを保持するクライアントと同様にDBIもforkした子供が親のコネクションをそのまま使うことはバグの原因になります。特にトランザクションの処理等で重大な問題が起こる可能性がある。 解決策は、 DBIのコネクションを親で作らないで、子供で独自に作る 親で作ってしまったコネクションを子供が安全にDESTROYし、再接続する のどちらかになります。ここで問題は2で
InactiveDestroyのアホな使い方 - D-6 [相変わらず根無し]
InactiveDestroyのアホな使い方 2011年4月22日 18:32 D | ブログ記事のURL | コメント(0) | トラックバック(0) WebAppで DBIをなんらかの方法でDBに接続して、で、リクエストが終わったら接続を解除して・・・とかしたいとするじゃないですか。具体的な実装はScope::Containerでもなんでもいいんですけど。 それでなんかしらんけど、アクセスするたびに三つずつDB接続が残る、という現象に遭遇したわけですよ。最初は普通に「あれ、Scope::Containerの使い方間違ってたか」とか思ってたんですが、何をしてもダメだし、Scope::Containerに手を加えて現在の保持してる変数を抜き出しても何もない。DBI::db へのリファレンスがないのに接続が切れないなんて・・・と途方に暮れることと数時間。 ・・・やっちまったよ。ワーカーも同じ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Perlゼミ(サンプルコードPerl入門)
