JVM remains attached to the Runtime process, the first time Oracle Forms application calls out to Java on the server, for the remainder of the process's life, even though the process may never call out to Java again. Given that each Forms Runtime session creates its own JVM instance, the amount of resources consumed on the server can become significant.

In a JVM Pooling environment, Forms Runtime processes share JVMs. A single JVM is capable of handling multiple Forms sessions from different Runtime processes. The pooling environment helps in greatly reducing the memory footprint on the hosted machine by eliminating the need of attaching one JVM per Runtime process. This environment is configurable. Forms administrators can set various parameters and tune the environment based on their needs and requirements. A limit on the number of Runtime sessions managed by a single JVM process in the pool can also be set.

When using JVM pooling, a JVM Controller is created. This is a JVM with specific responsibilities. Besides accepting connections from Runtime processes, it is also responsible for creating new JVMs when necessary. A new JVM process (also referred to as a Child JVM) is created only when the Controller finds that the existing JVMs in the pool (including itself) are unable to accommodate further sessions from Runtime processes.

Oracle Forms JVM pooling works with applications that used the Forms Java Importer during development. The Java Importer allows developers to reference Java classes from PL/SQL at design time. At runtime, the Java classes are loaded and executed by the JVM(s) as needed. Forms JVM pooling also works with Forms' ability to call out to Oracle BI-Publisher and Oracle Reports. Enabling the JVM pooling feature is recommended if any applications being executed fall into one of the aforementioned cases.

For information on the Java Importer, see Oracle Form Builder Online Help.