Skip Headers
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2)
B14032-03
  Go To Documentation Library
Library
Go To Product List
Product
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

7.4 About The JVM Controller

For each Oracle Forms session, there is one Oracle Forms Runtime Process on the application server. This process is where Oracle Forms actually runs, as well as manages the database connection; queries and updates data; runs any PL/SQL in the Form; executes triggers; and so on.

The Oracle Forms Runtime Process also contains the JVM to run Java in your application. As an optimization feature, the JVM is only started if the Oracle Forms application uses the Java Importer. For applications that do not use it, there is no extra memory consumption for the JVM.

JVM pooling is a new process that contains the JVM controller. With JVM pooling, the JVM runs outside of the Oracle Forms Runtime Process. The JVM can also be shared by multiple Oracle Forms Runtime Processes. The JVM controller process is not a JVM itself, but a container that contains a JVM in a similar way that the Oracle Forms Runtime Process contains an in-process JVM.


Note:

Use of JVM pooling is optional. Administrators can choose to not use JVM pooling and have the JVM contained in the Oracle Forms Runtime Process.

When an Oracle Forms Runtime Process needs to execute Java, it sends a message to the JVM that is contained in the JVM controller. The JVM creates a new thread for that Oracle Forms Runtime Process. The JVM then continues to listen for the next new request from a different Oracle Forms Runtime Process while the newly created thread processes the request and sends the results back to the Oracle Forms Runtime Process. For the life of this Oracle Forms session, the Oracle Forms Runtime Process communicates directly with that thread.

Since each Oracle Forms Runtime Process has its own thread within the JVM, there is concurrency. If the JVM reaches a specified number of concurrent requests, it will spawn a child JVM to share the load. Moreover, it's possible to have multiple JVM controllers, each of which may have multiple child JVMs.

For example, different Oracle Forms applications may want to use different JVMs with different options or classpaths. You can specify which JVM controller an Oracle Forms application should use in the named sections of the Oracle Forms configuration file (formsweb.cfg). See Section 7.5.14, "About Child JVMs" for more information.

Figure 7-3 shows an example of what an environment might look like using JVM pooling. There are two JVM controllers: the first one is using only its in-process JVM, the second one is using three JVMs.

Figure 7-3 Multiple JVM Controllers with Child Processes

Description of Figure 7-3  is in the surrounding text

Although it's not shown in Figure 7-3, each JVM controller has a unique name which is used in starting and stopping, or for referencing in the Oracle Forms configuration file.

Figure 7-3 is conceptual only in that it shows different Oracle Forms applications using different JVM controllers. However, the Oracle Forms Runtime Process does not communicate with the JVM controller, but directly with one of the available JVMs. Therefore, the first two clients in the diagram can only use the in-process JVM; the rest have three available JVMs to work with.