State Management Concerns

The application server is stateless, which means that it doesn’t keep any information (state) for its clients between calls to it. For one reason, calls to the application server can actually execute on different servers. When you are using Java in the application server, be careful to not leave state in the JVM that would cause your application to fail if a different application server (which would use a different invocation of the JVM) is used for subsequent calls. One method to leave state in the virtual machine is to use static (class) variables.

Similar considerations to these apply using Java in Application Engine programs, although here the difficulty arises when you try to checkpoint and then restart the program. The restart starts with a JVM invocation that doesn’t have any of the state you might have stored into the JVM before the checkpoint.

Variables of the type JavaObject cannot have global or component scope because of this lack of ability to save the state of these objects.

An example of this is issuing messages. When you're running with PeopleSoft Pure Internet Architecture and issue a message, the message is produced by an end-user action, so the Application Server gathers up its state to return it to the browser. This state saving attempts to save the current PeopleCode execution state, causing it to issue an error because of the JavaObject.

The solution is to not have any non-null JavaObject objects when the message is issued.

The following is a simple Java program:

public class PC_Java_Test{

public String pcTest(){

   String message;

   message = "PeopleCode is successfully executing Java.";

   return message;
   }
}

Here is the PeopleCode that calls this Java program. Note that the JavaObject is set to NULL before the message is issued.

&java_test = CreateJavaObject("PC_Java_Test");
&java_message = &java_test.pcTest();
&java_test = Null;
WinMessage(&java_message);

In SavePreChange, Workflow, or SavePostChange PeopleCode the situation is more complicated. Usually messages with a zero style parameter (no buttons other than OK and perhaps Explain, therefore no result possible except OK) are queued up by the Application Server. They are output by the browser when the service completes, so the serialization won't happen until after the PeopleCode has finished, so you won't have to set your JavaObject to null. With other kinds of messages, you must do this.