回答編集履歴
1
**完全に別のアプローチとして**
answer
CHANGED
|
@@ -1,3 +1,23 @@
|
|
|
1
1
|
> そもそも基本的なことに立ち返りますが、既存側と追加WEBAPIプロジェクト側でトランザクション処理を行っていさえすれば、競合起こった場合などしっかりロールバックを行い、心配いらないということなのでしょうか。
|
|
2
2
|
|
|
3
|
+
--誤解を招く表現だったので修正/追記--
|
|
4
|
+
ご質問にある「競合」がどこまでを指しているか次第ではありますが、
|
|
5
|
+
トランザクション機能を備えたRDBMSを使用したシステムの場合で
|
|
6
|
+
同時アクセスが想定されるケースの場合、
|
|
7
|
+
一般的にはトランザクション分離レベルを適切に設定し、
|
|
3
|
-
|
|
8
|
+
クライアント側（既存アプリ、web-API）でトランザクション処理を行うことで、
|
|
9
|
+
ロックの取得及び問題発生（RDBMSの把握する問題及び、アプリケーションが問題と判断する場合）時にロールバックを行う事が可能です。
|
|
10
|
+
|
|
11
|
+
適切なトランザクション分離レベルや、トランザクションに含めるべき範囲、
|
|
12
|
+
そもそもRDBMSの機能で実現可能なのかの判断については何をもって「競合」とするかの定義次第になるので、
|
|
13
|
+
まずはどういった競合が発生し、
|
|
14
|
+
競合発生時にアプリケーションの仕様として正しい挙動はどういうものかを定義するところからアプローチするところからスタートかなと思います。
|
|
15
|
+
（例えば、ほぼ同時に更新があった場合、後から更新した方はエラーが発生してほしいのか、先行の処理終了後のデータを元に処理を実施してほしいのかetc...）
|
|
16
|
+
|
|
17
|
+
「今回抜粋されたソースコードの部分だけ」を見ると、最低限、既存アプリを追加プロジェクトと同じ粒度・処理のトランザクションをかけるように処理を追加する必要があるように見えます。
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
**完全に別のアプローチとして**
|
|
21
|
+
追加プロジェクトの方は元々webアプリケーションとして開発されている（=同時アクセスに対する競合防止処理が実装されている）事が保証されているのであれば、既存アプリから直接DBにアクセスするのをやめて、全て追加プロジェクトのweb-API経由でデータ更新を行うように修正するというのも一つの手だと思います。
|
|
22
|
+
オーバーヘッドが増えてパフォーマンス的には不利になりますし、セキュリティ的に考えることが増え、既存アプリの作りによってはほぼ作り直しのような状態になる可能性があると思いますが、
|
|
23
|
+
同じ処理が二つの処理系にそれぞれ記述されているという永久に続く二重メンテナンスから解放されるという大きなメリットがあるので、個人的には好きな方法です。
|