>>790
MDISのケースは多分、図書館内端末用の界面にそのままWebを接続しただけだろ。
この場合、見た目は問題なく動く。
リソース枯渇のケースはコードから落とすしかないが、レビューが新規コードだけなら無理だ。
（この場合は新規コードはほぼ無しで、問題は今動作しているコード内にあるから）
おそらくMDISもB方式で、自前でコネクションプーリングしてる。
これは館内端末用で、端末に行列が出来ているかどうかは知る由もないから、closeはタイムアウトで10分とした。
ここまでは妥当な設計で、館内端末なんて高々数十台だし、問題なく動く。

問題はこれをそのままWeb側にも解放したことで、
この場合は一気に端末数が無限大になるのと等価で、コネクションが枯渇した。それだけだろ。
本来は、
D. Webからの入力を受ける「仮想端末」を用意し、Web入力は一旦全部そこで受けてからDBアクセス。
E. open/closeを毎回やるようにする。(Aと同じ）
のどちらかが必要で、本来はDの方がいいし多分そうしていると思う。
Dの場合はDDoS時にも館内端末は無傷で済む。
追加コードは仮想端末部分だけであり、既存コードには一切手を入れる必要がない。
Eの場合は全体のパフォーマンスが「いちいちopen/close」分だけ落ちる。
とはいえ真面目にDBを組んであればUIからでは見えないとも思う。
変更はopen/closeが内部APIで隠蔽されていれば数行、といったところか。
(そうなっていない場合は全体ソースを見直す必要があり、現実的ではない）