[pgpool-general-jp: 120] pgpool3.2+JDBC環境でのreplication_strictの挙動について

[tutui-t ＠ sys.tosho.co.jp]

こんにちは。
筒井と申します。

pgpool3.2のレプリケーションモードで、
デッドロックのような現象が発生することがあります。
パケットを取って調べてみたところ、
JDBC経由のクエリの場合、
replication_strictをtrueにしていても、
pgpoolは、masterからのレスポンスを待たずに
secondaryにリクエストを投げました。
これは正しい挙動なのでしょうか？



                     ---- postgresql(master)
  web ---- pgpool --|
                     ---- postgresql(secondary)


上記のような構成を作って確認しました。
すべて単独のホストで、
OSは、pgpoolがCentOS4.3、
postgresqlがSolaris10(SPARC)、
webサーバがSolaris8(SPARC)です。
webサーバにサーブレットコンテナを入れ、
アプリケーションを動かしています。

postgresql : 8.2.4
pgpool : 3.2
JDBC : postgresql-8.2-505.jdbc3.jar

サーブレットコンテナ : Resin 2.1.17
JDK : 1.4.2_08


上記構成では、トランザクション開始、テーブルロックの後、
updateコマンドを一つだけ発行してみました。
以下、psqlで実行した場合とJDBC経由の場合の結果について、
簡単な流れを記します。
JDBCの場合は、jspで、
  connection.setAutoCommit(false);
  stmt = connection.createStatement();
  stmt.executeUpdate("UPDATE 〜");
  connection.commit();
のように実行しています。
（テーブル名：test_data）


・psqlで実行した場合
 src        dst        protocol
pgpool     master      postgres    Request BEGIN;
master     pgpool      postgres    Response BEGIN
pgpool     secondary   postgres    Request BEGIN;
secondary  pgpool      postgres    Response BEGIN
pgpool     master      postgres    Request LOCK test_data;
master     pgpool      postgres    Response LOCK TABLE
pgpool     secondary   postgres    Request LOCK test_data;
secondary  pgpool      postgres    Response LOCK TABLE
pgpool     master      postgres    Request  （UPDATE発行）
master     pgpool      postgres    Response UPDATE 1
pgpool     secondary   postgres    Request  （UPDATE発行）
secondary  pgpool      postgres    Response UPDATE 1
pgpool     master      postgres    Request COMMIT;
master     pgpool      postgres    Response COMMIT
pgpool     secondary   postgres    Request COMMIT;
secondary  pgpool      postgres    Response COMMIT


・JDBC経由の場合
 src        dst        protocol
pgpool     master      postgres    Request S_1 BEGIN
pgpool     secondary   postgres    Request S_1 BEGIN
master     pgpool      postgres    Response BEGIN
secondary  pgpool      postgres    Response BEGIN
pgpool     master      postgres    Request  （LOCK test_data）
pgpool     secondary   postgres    Request  （LOCK test_data）
master     pgpool      postgres    Response LOCK TABLE
secondary  pgpool      postgres    Response LOCK TABLE
pgpool     master      postgres    Request  （UPDATE発行）
pgpool     secondary   postgres    Request  （UPDATE発行）
pgpool     master      postgres    Request S_2 COMMIT
pgpool     secondary   postgres    Request S_2 COMMIT
master     pgpool      postgres    Response COMMIT
secondary  pgpool      postgres    Response COMMIT


カッコ内は私による補足です。クエリの文言など、
読み取れる部分で流れを追ったので、
上の説明では情報が不足しているかもしれません。
その場合は、pgpool、postgresqlのデバッグ出力を含め、
あらためてお知らせします。


replication_strictがtrueの場合、
masterのResponseを待って処理完了と見なし、
つづいてsecondaryにRequestを投げると理解していたので、
JDBCの場合の挙動は予想していませんでした。
LOCKのあたりでこのような挙動を示していると、
複数のセッションの場合、
デッドロックの恐れがあるのではないかと思いますが、
この理解で正しいでしょうか？

同じような現象を確認された方はいらっしゃいますか？