Java Oracleのストアドプロシージャ、良いアイデアですか？
PL/SQLパッケージからのUDP通信を可能にする非常に小さなシムとしてJavaストアドプロシージャを使用することを検討しています。 Oracleは、そのUTL_TCPと一致するUTL_UDPを提供していません。 Javaを使用するサードパーティのXUTL_UDPがありますが、これはクローズドソースです（つまり、実装方法がわからないため、クローズドソースを使用したくない）。
ネットワークに関するPL/SQLとJavaストアドプロシージャの重要な違い：PL/SQLソケットはdbms_session.reset_packageが呼び出されると閉じられますが、Javaソケットは呼び出されません。ティアダウン/再接続のコストを回避するためにソケットを開いたままにしたい場合は、reset_packageを使用しているセッション（mod_plsqlやmod_owa HTTPリクエストなど）ではそれを行うことができません。
これまでに、Oracleの本番環境でJavaストアドプロシージャを使用したことがありません。これは非常に大きく、頻繁に使用されるデータベースであり、この特定のシムも頻繁に使用されます（PL/SQL RFC 5424 Syslogクライアントとローカルrsyslogデーモン間のUDPブリッジとして機能します）。
私は悲惨と恐怖に身を任せていますか、それともJavaストアドプロシージャは10gでの使用に十分安定していて堅牢ですか？組み込みJVM、jit、ガベージコレクション、または頻繁に使用されるデータベースに影響を与える可能性のあるその他の問題に疑問を感じています。
Oracleが長年にわたって導入してきたすべての新しいPL\SQLアドオンを構築するための主な方法の1つは、組み込みJVMを使用することなので、問題は少ないと思います。私は過去にそれらを使用したことがあり、それらがPL\SQLプロシージャよりも最悪ではないことを発見したので、常に実行していることを必ずしも実行する必要はありませんが、迅速な操作で実行できます。いくつかの問題があります。JVMは現在のリリースよりも1世代または2世代遅れていることが多く、最近の歴史ではこれについては不明ですが、OracleはDBとJavaの両方のソースです。静的メソッドで機能をラップし、それをPL\SQLブロックでラップする必要があるという事実は、一種の面倒です。 「宗教的な問題」以外には、それらを使用することに他の問題はまったくありません。
ストアドプロシージャは良い考えですか？
ストアドプロシージャはかなりのCPUオーバーヘッドを追加し、OracleデータベースはCPUに非常に貪欲になる傾向があります。 CPUが足りなくなった場合は、うんざりしています。したがって、現実的なベンチマークを作成して、データベースに問題が発生する可能性がないかどうかを確認することを強くお勧めします。
ストアドプロシージャを実行するオーバーヘッドが問題にならないと想定して、Javaこれを使用することを躊躇しません。Oracleが最初に実装したJavaストアドプロシージャOracle 8i（8.1.5）では、これは1999年2月にリリースされたため、この機能は数十年にわたってリリースされており、バグを修正するためにいくつかのメジャーリリースがありました。