On 15/09/2014 7:03 AM, Chris Travers wrote:
I have a few questions on this, the answers of which may help answer
your question:
1. How well does having a server-side JVM work, resource-wise, when
you have a forked process model like PostgreSQL? Does having the
additional JVM's pose performance and competition for resources that
lighter languages would not?
I don't think this is really a concern when connection pooling is used
(otherwise you end up creating a new JVM per connection which is indeed
problematic).
2. What is your specific use case for a trigger in Java?
The main drivers are:
1. Not having to learn yet another language. I find the expressiveness
and readability of the other scripting languages very clunky
compared to Java.
2. Ease of porting triggers across databases. The only thing that
really changes across databases is how triggers interact with
input/output parameters. The main body remains the same (thanks to
JDBC). This is quasi portability in the sense that the underlying
SQL is itself quasi portable, but I find it a much more compelling
approach than having to rewrite the triggers for each database type.
Gili
