Q&A
一般ユーザーが自分のアカウントの管理を行う RESTful API が「APサーバー」に用意されているが、「システム管理者がアカウントの管理」を行う場合は複数のユーザーアカウントを同時に操作するのでトランザクション処理したいということですか？ であれば、必要な機能を持たせた管理者用の API を新たに作って追加するという話になると思うのですが、そういうことは考えないのですか？
とあるシステムにて、システム管理者がアカウントの管理などを行うための
機能を開発しています。
本システムはAPサーバとDBサーバに分かれてRESTでやり取りしており、
本仕組みにてトランザクションを使って複数のRESTをまとめて更新する方法を
検討しています。
下記HPを参考に、DBサーバ側に一時的にリクエストで受け付けた
更新内容をスタックする仕組みを作り、APサーバ側からコミット開始リクエストを
受けたタイミングでDBに向けてため込んだ一連の処理を実行すると言う仕組みを
考えているのですが、そこで２点質問です。
https://qiita.com/uenosy/items/89de9b1d0d2842e358e9
１）
それぞれのRESTリクエストで投げ込まれる各更新指示を一時的に
DBサーバ側のどこにため込むかで悩んでいます。
普通にインスタンスを生成してそこに登録してもRESTの各処理同士で参照することは
出来ないような気がしますし、かと言ってDBやファイルに登録するのも排他制御や、
作ったデータの後片付けがあるため、出来れば避けたいと思っています。
１つ思いついたのがシングルトンクラスにキューを持たせて、
それをRESTの各処理で参照し合うと言う方法なのですが、
正直シングルトンをあまり使ったことが無く、
本用途が正しいのかがイマイチ分かりません。
このような実装のケースとしてシングルトンを使うのが適当なのかどうか、
また、他に実装可能な方法がございましたらご教示ください。
２）
そもそもこの実装ですがRESTful設計における
ステートレス性に違反するものなのでしょうか。
また、その場合に起こりうる具体的なリスクを教えてください。
よろしくお願いいたします。
ご回答ありがとうございます。
少しぼやかしていますが、具体的にはユーザーのテーブルに趣味や特技などのマスタ情報が中間テーブルを挟んでぶら下がっており、AP側の各機能によってそのうちのテーブルの幾つかを更新すると思ってください。
・ある処理はユーザと趣味のテーブルを更新し、ある処理はユーザと特技のテーブルを更新すると言う組み合わせのAPIを作るのが手間であること
・DB側に各テーブル別の更新処理が作成済みであるため、本処理を再利用したい
ために、本機能の検討をしており、質問をした次第です。
以下の疑問があります。
(1)APサーバがRESTfulなだけですよね？
(2)DBサーバはAPサーバからはSQLのみでアクセスされるんですよね？
(3)APサーバやDBサーバは他の機器も含め具体的にどう繋がっていますか？
(4)各データの量やリクエストの量はどの程度の規模ですか？
(5)Qiitaの記事を理解していますか？(トランザクションを分ける意味/ACID)
(6)今回の要件にQiitaの記事の何を使おうとしていますか？
(7)貯め込「まないといけない」理由は何ですか？
これだけあるということは、検討と言っても内容を把握してない人に聞ける段階ですらないと思います。
内容を把握している人に聞きましょう。
十分検討した(要件を整理し、問題を明確にした)上で、その技術的なところをピンポイントで聞けるなら、ここで聞いてもいいかもしれません。
最後に、ただの当てずっぽうですが、大雑把に言って、ロールバックをアプリで自力で実装するリスクやコストは高いので、DBでやるべきです。
あなたの回答
tips
プレビュー
