solutions
Some problems and their solution.
Java™ is a registered trademark of Sun Microsystems, Inc. in the United States and other countries.
When writing the PL/Java, mapping the JVM into the same process-space as the PostgreSQL backend code, some concerns have been raised regarding multiple threads, exception handling, and memory management. Here is a brief text explaining how these issues where resolved.
Multi threading.
Problem
Java is inherently multi threaded. The PostgreSQL backend is not. There’s nothing stopping a developer from utilizing multiple Threads class in the Java code. Finalizers that call out to the backend might have been spawned from a background Garbage Collection thread. Several third party Java-packages that are likely to be used make use of multiple threads. How can this model coexist with the PostgreSQL backend in the same process without creating havoc?
Solution
The solution is simple. PL/Java defines a special object called the
Backend.THREADLOCK. When PL/Java is initialized, the backend will immediately
grab this objects monitor (i.e. it will synchronize on this object). When the
backend calls a Java function, the monitor is released and then
immediately regained when the call returns. All calls from Java out to backend
code are synchronized on the same lock. This ensures that only one thread at a
time can call the backend from Java, and only at a time when the backend is
awaiting the
return of a Java function call.
Exception handling
Problem
Java makes frequent use of try/catch/finally blocks. PostgreSQL sometimes use an exception mechanism that calls longjmp to transfer control to a known state. Such a jump would normally effectively bypass the JVM. Prior to PostgreSQL version 8.0, the error was propagated before the actual jump and then discarded, thus there was no way to catch and handle the error.
Solution
The backend now allows errors to be caught using the macros
PG_TRY/PG_CATCH/PG_END_TRY and in the catch block, the error can be
examined using the ErrorData structure.
PL/Java implements a java.sql.SQLException
subclass called
org.postgresql.pljava.ServerException. The ErrorData can be retrieved and
examined from that exception. A catch handler is allowed to issue a rollback to
a savepoint. After a successful rollback, execution can continue.
Java Garbage Collector versus palloc() and stack allocation.
Problem
Primitive types will be passed by value always. This includes the String type (this is a must since Java uses double byte characters). Complex types are however often wrapped in Java objects and passed by reference. I.e, a Java object will contain a pointer to a palloc’ed or stack allocated memory and use native JNI calls to extract and manipulate data. Such data will become “stale” once a call has ended. Further attempts to access such data will at best give very unpredictable results but more likely cause a memory fault and a crash.
Solution
The PL/Java contains code that ensures that stale pointers are cleared when the MemoryContext or stack where they where allocated goes out of scope. The Java wrapper objects might live on but any attempt to use them will result in a “stale native handle” exception.