Q&A
回答いただきありがとうございます。
回答いただいた内容を熟読し、再度考慮してみます。
テーブルBに集計結果を反映しなければならないのは、テーブルA・テーブルBが自身の開発物とは別の連携先システム内のDB内にあるためで、テーブルBは常に最新の状態が保たれていないとならないという制約があるためです...
###前提・実現したいこと
- java7
- jdbc
- postgresql
初歩的な質問で恐縮です。
以下の様なテーブルAとテーブルBがあり、
テーブルAにデータを追加していき、テーブルBの件数を更新しようとしています。
テーブルA
| id | グループ名 |
|---|---|
| 1 | aaa |
| 2 | bbb |
| 3 | aaa |
| 4 | aaa |
テーブルB
| グループ名 | 件数 |
|---|---|
| aaa | 3 |
| bbb | 1 |
以下の様に処理を記載しました。
１．トランザクションを開く(Connection.setAutoCommit(false))
２．テーブルAへの行追加SQLを実行(insert テーブルA)
３．テーブルBに件数を反映する集計SQLを実行(update テーブルB set ... from(select ... from テーブルA))
４．コミット(Connection.commit())
処理が1つだけ(直列)の場合は上記でうまくいくのですが、並列で実行した場合、
行追加は全て行われるのですが、集計SQLの結果がテーブルAの状態と合致しなくなります。
■例：10並列で処理を実行
テーブルAのレコード数⇒10件
テーブルBの件数フィールド値⇒7
※この場合、本来は10に更新したい
###試したこと
Connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE)
を指定してみましたが、同時更新のため直列化アクセスができませんでした(当然ですが...)
###困っていること
最新の結果が反映されるようにしたいのですが、どういったアプローチをすればいいのかわかりません。
補足条件：テーブル構成は変更できません
回答4件
0
トランザクションの開始から終了までを1つのメソッドでくくり、
java
1public synchronized void transactionHoge() { 2 //シンクロナイズを書くことで、このメソッドは他からは呼ばれない。 3}
のような制御はいかがですか。トランザクション張ってる間の変動は止まるはずです。
投稿2017/07/14 08:37
総合スコア716
0
ベストアンサー
- 設計について
⇒そもそもテーブルBは必要ですか？
集計時にテーブルAを見るようにしてはいかがでしょうか。
（すみません、他の回答で縛りがあるんですね）
- SQLの並列処理について
⇒10ではなく7で更新されてしまう原因は理解されているようにも見えますが、
テーブルAに入れた後、コミットしていないため、
同時実行すると以下の順番で更新されると、10以外のデータで更新されます。
（例）
処理１ テーブルA インサート
処理２ テーブルA インサート
処理３ テーブルA インサート
処理１ テーブルB 更新（1件）
処理２ テーブルB 更新（1件）
処理１ コミット
処理３ テーブルB 更新（2件）
処理２ コミット（テーブルB 1件）
処理３ コミット（テーブルB 2件）
テーブルBを残したまま、対策する場合、以下のような方法があります。
＜方法１：強制的に直接処理にする＞
テーブルBをロック（ロックできなければ、待機）、
テーブルAをインサート、
テーブルBの更新・コミット
テーブルBの解放
＜方法２：本当の同時以外は回避する＞
テーブルAをインサート、コミット
テーブルBの更新・コミット
※9になる可能性もあります。
- バグもなく、直接処理ではなく、並列処理させたい！という場合
⇒テーブルAにインサートした直後のテーブルBとの差異は無視するという手もあります。
つまり、参照の時に、
テーブルBの更新、コミットを行ってから、
テーブルBのデータを抽出する。
という方法もあります。
（この場合、そもそも、抽出時に集計した方が早いのですが・・・・・・）
- その他
⇒テーブル構造のしばりがあっても、
そもそもその項目を使わない（構造はそのまま放置）のもありかとも思います。
投稿2017/07/14 08:36
総合スコア760
一先ず、開始時にLOCK TABLE テーブルB IN EXCLUSIVE MODEでテーブルBをロックするようにして、目的の動作を達成しました。ありがとうございました。
0
並列で処理したら、他のトランザクションでinsertされた行はcommitされるまで見えないので、
当然誤差がでますよ。
３．テーブルBに件数を反映する集計SQLを実行
を全てのinsertの並列処理のcommitが終わった後に1回やればいいだけだと思いますが、、、
投稿2017/07/14 08:28
総合スコア1400
回答ありがとうございます。
実際の処理では、insert処理(および更新処理)がWebリクエストに応じて発生するため、全てが終わるという区切りがありません。定周期で集計SQLを実行するのもNGといわれておりまして、どうすればいいか悩んでおります。
１．トランザクション
２．テーブルAへの行追加SQLを実行
４．コミット
上記の処理が終わったら、別スレッドで以下を実行。
１．トランザクション
３．テーブルBに件数を反映する集計SQLを実行
４．コミット
これで明確な前後関係ができますが、、、
そもそもどこまでの対応が出来るかですが。。
javaの実装？クラスの作成？ライブラリの追加？SQLの修正？トリガーの追加？その他？？
なるほど、上記の方法であれば、全てのInsertがコミットされた後に、必ず一度は集計SQLが走りますね。
ありがとうございます。
テーブルAにトリガーを使用する方針で進めていたのですが、DB構成には直接手は加えてほしくないといわれてNGとなってしまいました。
0
テーブルA、Bそれぞれに更新時刻カラムを追加し、最新のものをBにも追加して、
Bテーブル更新時にAの最新時刻がBのものより現在に近ければBを更新。
みたいなアプローチはどうですか？
あいまいな回答で申し訳ないですがアプローチという意味で・・・
投稿2017/07/14 08:06
総合スコア69
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/07/14 09:15