[sqlite3][ruby]busy_handlerを使ってみる

すっごいいまさらですが、sqlite2(Ruby/DBI)→sqlite3(sqlite-ruby)の移行に着手しています。

sqlite2の時は、アクセスが競合してBusyになった時のリトライ処理が見あたらなかったので、自前でこんなことをしていました。

10.times_retry(DBI::DatabaseError,1) {
@dbh = DBI.connect(@@db_prefix+@db_filename, "", "" ) unless @dbh
}

(DBに接続を試みて、DBI::DatabaseErrorが発生したら、1秒sleepしたあとリトライ、１０回試みて、それでも駄目だったらDBI::DatabaseErrorをraiseします。)

Rubyらしいエレガントなコード♪とか思っていたのですが、プログラムのあちこちにこれが散見される状態というのもなんだか悲しい。

sqlite-rubyでは、busy_handlerという機能が実装され、こういう事はライブラリ内でやってくれるようになりました。ただ、これのサンプルが見あたらない。
あれこれ試行錯誤していちおう動くようになったのですが、なんだか謎の部分も残っているので、ご存じの方、教えていただけると嬉しいです。

片方のシェルで、sqlite3を走らせて、ロック状態にしておきます。

sqlite> BEGIN;
sqlite> insert into fragments (user_id,content,lastmod,bornin) values(0,"test","2009-04-01 12:59:15","2009-04-01 12:59:15");

(sqlite2の頃は、BEGIN;した時点でロックされていたのですが、今のバージョンでは、実際にロックが必要になった時点でロックするみたいです)

もう片方でirbを走らせて、こんな感じでロックに激突させます。

require 'rubygems'
require 'sqlite3'
dbh = SQLite3::Database.new("test.sqlite3")
#dbh.busy_timeout(10000)
dbh.busy_handler{|data, retries|
print "in busy_handler data is ",data,"\n"
print "retries is ",retries,"\n"
sleep 1;
(retries<=3)
}
dbh.execute("insert into fragments (user_id,content,lastmod,bornin) values(0,'test','2009-04-01 12:59:15','2009-04-01 12:59:15');")

それいけっ！

irb(main):013:0> dbh.execute("insert into fragments (user_id,content,lastmod,bornin) values(0,'test','2009-04-01 12:59:15','2009-04-01 12:59:15');")
in busy_handler data is nil
retries is 0
in busy_handler data is nil
retries is 1
in busy_handler data is nil
retries is 2
in busy_handler data is nil
retries is 3
/usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/errors.rb:94:in `check': database is locked (SQLite3::BusyException)
from /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1/lib/sqlite3/resultset.rb:76:in `check'
:

よしよし。

まとめ：busy_handlerの使い方

• 　DBに接続したあたりで、

  dbh.busy_handler{|data, retries|
  # BUSYだった時の処理
  }
  

  という具合にして宣言する。このコードはすぐ実行されるわけではなく、DBにアクセスしてBUSYだった時に初めて実行される。

• retriesに試行回数が入っている。
• (謎)busy_timeoutの挙動が謎。APIリファレンスを見ると、busy_timeout(1000)ってしたら、一秒おきにリトライしそうな物ですが、実際には丸無視しているように見えます
• しょうがないので、busy_handler内でsleepします
• (謎)dataって何でしょうね？
• busy_handlerのブロックの評価結果がtrueであれば、リトライが実施されます。falseであれば、例外が投げられます。

最後の項目、return false って書くわけじゃなくて、ブロックの評価結果が使われるところがポイントかと。
上のサンプルでは、３回まではリトライして、それで駄目なら例外を投げるようなコードになっています。