D'après mon expérience, pl/java a quelques problèmes majeurs :
- Il est difficile de l'installer sur un serveur postgresql. Même si vous trouvez une version binaire pour votre version de postgresql (ce qui est également difficile), il faut jongler avec la configuration et le chemin de la bibliothèque.
- Le premier appel à la procédure stockée Java entraînera un nouveau processus JVM. Les processus JVM sont limités à la connexion et nécessitent une certaine quantité de mémoire pour le tas Java, donc si vous utilisez un pool de connexions, vous vous retrouverez avec 10 à 20 JVM démarrées et inutilisées la plupart du temps, consommant la RAM de votre serveur
- pl/java peut communiquer avec la base de données postgresql à l'aide d'un pilote JDBC personnalisé qui émule l'utilisation courante de JDBC, mais présente des problèmes d'implémentation qui peuvent vous surprendre. Surtout si vous voulez utiliser des curseurs JDBC ou d'autres choses pas si courantes.
- La journalisation pl/java est plutôt spéciale - c'est à cause de l'implémentation de la gestion interne des erreurs postgresql. Par exemple - si vous enregistrez quelque chose avec l'api de journalisation Java au niveau du journal ERROR - cela mettra fin à votre connexion au serveur.
- pl/java a de très bonnes performances de traitement des données par rapport à la logique java basée sur le serveur d'applications, mais il est totalement non évolutif - les procédures pl/java sont entièrement monothread - postgresql interdit les procédures multithread
- Si vous utilisez le pilote JDBC interne et que votre instruction SQL contient des erreurs - vous vous retrouverez avec un message d'erreur crypté dans le journal postgresql - totalement sans rapport avec le problème réel.
En conséquence, vous pouvez utiliser les procédures pl/java avec un certain succès, mais vous devez le faire très soigneusement et vous devez probablement penser à améliorer la conception de votre application.
