Meiner Erfahrung nach hat pl/java einige große Probleme:
- Es ist schwierig, es auf einem Postgresql-Server zu installieren. Selbst wenn Sie einen binären Build für Ihre Postgresql-Version finden (was auch schwierig ist) - es erfordert etwas Konfigurations- und Bibliothekspfad-Jonglieren.
- Der erste Aufruf der gespeicherten Java-Prozedur führt zu einem neuen JVM-Prozess. JVM-Prozesse sind verbindungsbezogen und benötigen eine gewisse Menge an Arbeitsspeicher für Java-Heap. Wenn Sie also den Verbindungspool verwenden, werden am Ende 10–20 JVMs gestartet und die meiste Zeit nicht verwendet, was Ihren Server-RAM beansprucht
- pl/java kann mit der Postgresql-Datenbank kommunizieren, indem ein selbst erstellter JDBC-Treiber verwendet wird, der die allgemeine JDBC-Nutzung emuliert, aber einige Implementierungsprobleme hat, die Sie überraschen könnten. Vor allem, wenn Sie JDBC-Cursor oder andere nicht so übliche Dinge verwenden möchten.
- pl/java-Logging ist ziemlich speziell - es liegt an der internen Fehlerbehandlungsimplementierung von postgresql. Wenn Sie beispielsweise etwas mit der Java-Protokollierungs-API auf ERROR-Protokollebene protokollieren, wird Ihre Serververbindung beendet.
- pl/java hat eine sehr gute Datenverarbeitungsleistung im Vergleich zu anwendungsserverbasierter Java-Logik, aber es ist völlig unskalierbar - pl/java-Prozeduren sind vollständig Single-Threaded - postgresql verbietet Multi-Threaded-Prozeduren
- Wenn Sie den internen JDBC-Treiber verwenden und Ihre SQL-Anweisung Fehler enthält, erhalten Sie am Ende eine kryptische Fehlermeldung im Postgresql-Protokoll - völlig unabhängig von einem echten Problem.
Als Ergebnis - Sie können pl/java-Prozeduren mit einigem Erfolg verwenden, aber Sie müssen es sehr sorgfältig tun und wahrscheinlich müssen Sie darüber nachdenken, Ihr Anwendungsdesign zu verbessern.
