7.3 Design-time Considerations

This section contains the following:

• Section 7.3.1, "About Previous Versions of the Java Importer"

• Section 7.3.2, "Re-importing Your Java Code"

• Section 7.3.3, "About Sharing Static Variables Across Multiple JVMs"

7.3.1 About Previous Versions of the Java Importer

When the Java Importer was added to Oracle Forms, each Forms session that used the Java Importer had its own instance of the JVM to execute Java code. Each JVM consumes memory on the server, and if there are many concurrent users, the amount of memory consumed by the multiple JVM processes could become significant.

7.3.2 Re-importing Your Java Code

If you used the Java Importer feature of Oracle Forms prior to JVM Pooling, you will need to reimport your Java classes before using JVM pooling. When you originally imported your Java classes, PL/SQL wrappers for the Java classes were generated, which you can see in the Program Units that were created in your Form. However, the PL/SQL wrappers that are needed by the Java Importer are different.

From Oracle Application Server Forms Services 10g and onwards, the Java Importer generates the "new" PL/SQL wrappers. If you want to use the Java Importer, but don't wish to take advantage of JVM pooling, the in-process JVM will work with the new PL/SQL wrappers. It will also continue to work with the older-style PL/SQL wrappers.

If you use Java in your application, but don't wish to use JVM pooling, then you do not need to re-import your Java classes. The in-process JVM will work with previously generated PL/SQL wrappers and with newly generated PL/SQL wrappers.

Note: With an in-process JVM, the JVM is part of the Oracle Forms Runtime Process itself, and is not a separate process. When JVM Pooling is used, the JVM is a separate, external process to the Forms Runtime Processes.

7.3.3 About Sharing Static Variables Across Multiple JVMs

If you used the Java Importer feature prior to JVM pooling, each Forms Runtime Process had its own in-process JVM that is separate from all of the others. With JVM pooling, you have multiple Forms runtime processes running Java code within the same JVM. One advantage is the ability to share data between instances of a class by using static variables. However, static variables will be shared between instances of the same class within a JVM, but not across JVMs. You'll need to plan accordingly.

For example, suppose your loan class has a static variable called interestRate because all instances use the same interest rate in calculations. If you are using only one JVM, and one of the instances of your loan class changes interestRate, all of the other instances will be affected (which is what you want).

However, if the JVM controller has one or more child JVMs, there may be at least two JVMs. If interestRate changes in one JVM, the loan instances in the other JVMs won't see this new value. For more information about managing child JVMs, see Section 7.5.14, "About Child JVMs". Prior to JVM pooling, if you changed interestRate it wouldn't affect any other instances because each Oracle Forms Services Runtime Process had its own in-process JVM.

If you rely on static variables to share information between instances of your class, ensure that no child JVM is spawned by setting maxsessions to 65535.