src/pl/pljava/docs/solutions.html - hawq - Git at Google

 <html>

 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
 <meta http-equiv="Content-Language" content="en-us">
 <title>Some problems and their solution</title>
 <style>
 p {margin-top:0;
   margin-bottom:6.0pt;}

 h1  {margin-top:12.0pt;
   margin-bottom:3.0pt;}

 h2  {margin-top:12.0pt;
   margin-bottom:3.0pt;}

 h3  {margin-top:12.0pt;
   margin-bottom:3.0pt;}

 </style>
 </head>

 <body>

 <h1>Some problems and their solution.</h1>
 <p><font size="2">Java&#8482; is a registered trademark of Sun Microsystems, Inc. in the United States and other countries.</font></p>
 <p>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.</p>
 <h2>Multi threading.</h2>
 <h3>Problem</h3>
 <p>Java is inherently multi threaded. The PostgreSQL backend is not. There&#8217;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?</p>
 <h3>Solution</h3>
 <p>The solution is simple. PL/Java defines a special object called the
 <code>Backend.THREADLOCK</code>. 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.</p>
 <h2>Exception handling</h2>
 <h3>Problem</h3>
 <p>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.</p>
 <h3>Solution</h3>
 <p>The backend now allows errors to be caught using the macros <code>
 PG_TRY/PG_CATCH/PG_END_TRY</code> and in the catch block, the error can be
 examined using the <code>ErrorData</code> structure.
 PL/Java implements a <code>java.sql.SQLException</code>
 subclass called <code>
 org.postgresql.pljava.ServerException</code>. 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.</p>
 <h2>Java Garbage Collector versus palloc() and stack allocation.</h2>
 <h3>Problem</h3>
 <p>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&#8217;ed or stack allocated memory and use native JNI calls to
 extract and manipulate data. Such data will become &#8220;stale&#8221; 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.</p>
 <h3>Solution</h3>
 <p>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
 &#8220;stale native handle&#8221; exception.</p>

 </body>

 </html>
	<html>

	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
	<meta http-equiv="Content-Language" content="en-us">
	<title>Some problems and their solution</title>
	<style>
	p {margin-top:0;
	margin-bottom:6.0pt;}

	h1 {margin-top:12.0pt;
	margin-bottom:3.0pt;}

	h2 {margin-top:12.0pt;
	margin-bottom:3.0pt;}

	h3 {margin-top:12.0pt;
	margin-bottom:3.0pt;}

	</style>
	</head>

	<body>

	<h1>Some problems and their solution.</h1>
	<p><font size="2">Java™ is a registered trademark of Sun Microsystems, Inc. in the United States and other countries.</font></p>
	<p>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.</p>
	<h2>Multi threading.</h2>
	<h3>Problem</h3>
	<p>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?</p>
	<h3>Solution</h3>
	<p>The solution is simple. PL/Java defines a special object called the
	<code>Backend.THREADLOCK</code>. 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.</p>
	<h2>Exception handling</h2>
	<h3>Problem</h3>
	<p>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.</p>
	<h3>Solution</h3>
	<p>The backend now allows errors to be caught using the macros <code>
	PG_TRY/PG_CATCH/PG_END_TRY</code> and in the catch block, the error can be
	examined using the <code>ErrorData</code> structure.
	PL/Java implements a <code>java.sql.SQLException</code>
	subclass called <code>
	org.postgresql.pljava.ServerException</code>. 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.</p>
	<h2>Java Garbage Collector versus palloc() and stack allocation.</h2>
	<h3>Problem</h3>
	<p>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.</p>
	<h3>Solution</h3>
	<p>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.</p>

	</body>

	</html>