もう20年近く前になるが、初めてjavaのシステム開発をした時に、javaに強いとされるソフトウェア会社が何となく言っていたseasarを使うと言う言葉でdiコンテナを使ったシステムにした。
通信で受け取る複数の要素からなるデータのひとつひとつに対して、データベースに格納する際の編集処理を異なるクラスに処理させ、それぞれのデータに対して使用するクラス名はデータベースに定義してやるという設計にした。
我ながら、java素人にしては斬新な設計思想でかつ、diの使い方に対しても最適な設計だったと、今になって思っている。
当時勘違いしていたのは、diconファイルに全てのクラスを定義するのに、新たなクラスを追加した場合にdiconからの初期化を毎回呼び出すので、アプリケーションの終了なしで処理のメンテナンスができると思っていた。
javaのvmはずっと起動しっぱなしで外部からのデータ受信イベントでスレット生成してその中でdiconの初期化をするので、diconファイルと追加変更したクラスを差し替えれば、変更後の動作になると思っていた。
当時はシングルトンを正しく理解していなかったので、生成済みのリソースがそのまま返されるとは思っていなかったわけだ。
今考えれば、毎回diconの初期化をしていたら、処理が遅すぎて使い物にならなかったはずなのに、外部データの処理が追いつかないことなど無かったのだから、そこまで考えが至らなかったのだ。
処理時間至上主義のシステムだったので、インメモリデータベースに受信データを格納して、データ処理を指示する情報はハードディスクのOracleに保持していた。
外部データのパターンはそれほど多くなかったので、oracleのキャッシュでほとんどSQLは返されていたのでほとんどディスクアクセスしない状態だった。
何だか設計に対して尖っていたころの話だ。