2.3.11 Points to be considered when creating a batch application

This subsection describes the processing, for which you must take care when creating a batch application, and the functionality that you cannot use in a batch application. Confirm these contents, and then create a batch application.

Organization of this subsection

(1) Processes that require attention
(2) Functionality that you cannot implement in batch applications
(3) Points to be considered when using JavaVM end method

(1) Processes that require attention

You must take care of the following processing, when creating a batch application:

(a) File and directory operations

Do not operate the following files and directories in a batch application:

Files and directories below the Cosminexus installation directory

For details on the files and directories under the Cosminexus installation directory, see Appendix B Post-Installation Directory Configuration in the uCosminexus Application Server System Setup and Operation Guide.
Files and directories below the work directories of batch server

For details on the work directories of a batch server, see Appendix C.2 Work directory of the batch server in the uCosminexus Application Server System Setup and Operation Guide.

When handling the files and directories in a batch application, you cannot use a relative path as a path of the files and directories. If you want to acquire a relative path from a directory by executing the cjexecjob command, use the value of ejbserver.batch.currentdir. For details on ejbserver.batch.currentdir, see ejbserver.batch.currentdir property in the uCosminexus Application Server API Reference Guide.

The following example shows how to modify a batch application.

Before modification

File f = new File("DataFile.txt");

After modification

File f = new File(System.getProperty("ejbserver.batch.currentdir") + System.getProperty("file.separator") + "DataFile.txt");

(b) Using threads

A batch server does not wait for end of thread that is created or started by a batch application. When using threads in a batch application, you implement in such a way so that all the started user threads are completed before ending the batch application. User threads are out of scope of method cancellation.

If true is specified in the ejbserver.batch.application.exit.enabled parameter in the Easy Setup definition file, note the following points:

You cannot create a thread group (ThreadGroup).
If a handler inheriting UncaughtExceptionHandler that is an interface of java.lang.Thread class is registered in a batch application, the processing of the registered handler is executed, when invoking JavaVM end method. In this case, the jp.co.Hitachi.soft.jvm.SpecialThrowable exception might be passed in an argument of the uncaughtException method.

If a thread created by a batch application remains, the classes of the batch application or the used resources are not released. As a result, when you attempt to start next batch application, the batch application might fail to start. In a user thread, you cannot invoke the following batch server functionality:

Batch application execution functionality
EJB access functionality
Functionality provided by naming management
Functionality provided by resource connection and transaction management
GC control functionality
Functionality provided by container extension library

(c) Automatic closing of resources when ending JavaVM

On a batch server, a batch application is executed on JavaVM of the server. Therefore, if the implementation expects the processing of automatically closing resources, as a part of ending JavaVM, memory or file descriptor leakage might occur. For example, leakage occurs in the following cases:

If a ZIP file or a JAR file is open and if you do not explicitly close the file, C heap area leaks.
If you specify ejbserver.batch.application.exit.enabled=false in usrconf.properties on a batch server, the file is not deleted until the batch server stops even if you use java.io.File.deleteOnExit(). C heap area leaks until the batch server stops.

To avoid these problems, implement batch applications in such a way so that the resources close properly.

If you do not explicitly close files and sockets, the timing of resource release is indefinite. This might impact the execution of subsequent batch applications. Make sure to explicitly close files and sockets.

In the case of a batch server, you cannot use automatic closing of connection. Make sure to close connection inside batch applications.

(d) Using JavaVM end methods

If you specify true in the ejbserver.batch.application.exit.enabled parameter in the Easy Setup definition file, you can use the following JavaVM end methods:

java.lang.System.exit(int)
java.lang.Runtime.exit(int)
java.lang.Runtime.halt(int)

For details on the settings of the ejbserver.batch.application.exit.enabled parameter, see 2.3.10 Settings in the execution environment (batch server settings). For details on the points to be considered when using the JavaVM end methods, see (3) Points to be considered when using JavaVM end method.

(e) Using shutdown hook

If you specify true in the ejbserver.batch.application.exit.enabled parameter in the Easy Setup definition file, you can use shutdown hook in the following cases:

If you invoke JavaVM end method
If the main method returns
If an exception that occurs in the main thread is not caught

For details on the settings of the ejbserver.batch.application.exit.enabled parameter, see 2.3.10 Settings in the execution environment (batch server settings).

To Page Top

(2) Functionality that you cannot implement in batch applications

You cannot use the following functionality in a batch application. Take actions by using the procedure shown in Action.

Input from standard input

You cannot perform input processing from standard input that uses java.lang.System.in.

Action

Use a file when an input processing is required.
Using JNI

You cannot use the execution functionality of native libraries through JNI.

Action

When using JNI, use through container extension library. In that case, load native libraries in container extension library.
Replacing set of system properties

You cannot use the following method:
- java.lang.System.setProperties(java.util.Properties)
Action

Use java.lang.System.setProperty(String, String).
Reallocating standard output stream and standard error output stream

You cannot use the following methods:
- java.lang.System.setOut(java.io.PrintStream)
- java.lang.System.setErr(java.io.PrintStream)
Action

Do not use java.lang.System.out and java.lang.System.err. You directly use the PrintStream object that you want to output.

To Page Top

(3) Points to be considered when using JavaVM end method

If you specify true in the ejbserver.batch.application.exit.enabled parameter in the Easy Setup definition file, JavaVM is not ended even if you use the JavaVM end method in a batch application. In such case, you can end only the thread invoked by the JavaVM end method.

This subsection describes the points to be considered when using the JavaVM end method if you have specified true in the ejbserver.batch.application.exit.enabled parameter.

(a) Differences with Java language specifications

The specifications of the JavaVM end method used in a batch application are different from the Java language specifications. The following table describes the differences with Java language specifications.

Table 2‒10: Differences with Java language specifications
Field	In Java language specification	In batch application
End target	JavaVM	Thread which invoked JavaVM end method
java logic coded after invocation	Processing, coded after invoking JavaVM end method, is not executed.	Processing, coded after invoking JavaVM end method, is executed in the following cases: If JavaVM end method is coded in try block, corresponding `finally` block is executed. ^#1 If `java.lang.Thread.UncaughtExceptionHandler` is registered in thread, `UncaughtExceptionHandler` is executed. ^#1
Multiple invocation	Cannot be used.	Multiple invocation is performed in the following cases: If you invoke the same JavaVM end method from `finally` block as in the case of the thread that invokes the JavaVM end method If you invoke JavaVM end method from multiple user threads^#2, started from the batch application

#1: You might not be able to end the thread, if an exception occurs in the finally block and in the method invoked in the finally block, and execution of the finally block is interrupted in middle without catching the exception in the finally block.

In the following cases, the time might be required for ending a thread or you might not able to end the thread:

If Java program processing for which the time is required is coded in the finally block and in the method invoked in the finally block
Java program processing for which the time is required is coded in java.lang.Thread.UncaughtExceptionHandler

An infinite loop, monitor waiting by the synchronized statement, and waiting by java.lang.wait() are processes of a Java program that require time.

#2: User thread shows a child thread created by a batch application. Take care of the following, when using user threads:

If interruptedException is caught in the run() method, a user thread is not ended, and remains as it is.
If the main thread has ended even if the user thread remains, start of next application is accepted. However, memory leakage occurs.

Reference note: If you want to end JavaVM when executing the JavaVM end method, you specify false in the ejbserver.batch.application.exit.enabled parameter in the Easy Setup definition file. If you specify false, JavaVM ends for each batch server when executing the JavaVM end method.

(b) Processing when you invoke JavaVM end method

This subsection describes a processing, when you invoke JavaVM end method for each batch application.

If you invoke JavaVM end method in a batch application, implemented with a single thread

You end the main thread and end the execution of a batch application.

The following table describes the operations, when the JavaVM end method is invoked for multiple times.

Table 2‒11: Operations when JavaVM end method is invoked for multiple times (In the case of a batch application implemented with a single thread)
No.	Field	Operation
1	End reporting to batch application execution functionality	Report end only when you invoke first JavaVM end method. Do not report when you invoke second or later JavaVM end method.
2	Returning end code	The end code, specified in argument, is enabled when you invoke first JavaVM end method. The end code, specified in argument, is disabled when you invoke second or later JavaVM end method.
3	Thread, which invoked JavaVM end method	The thread ends irrespective of number of invocation of JavaVM end method.

If you invoke JavaVM end method in a batch application, implemented with multithread

A thread that invokes the JavaVM end method ends. The processing of other threads varies according to the source thread, from which the JavaVM end method is invoked.

If you invoke the JavaVM end method with the main thread, and if the main method returns or if an exception occurred in the main thread is not caught.

Batch application execution functionality executes interrupt of java.lang.Thread class for all running user threads.
If you invoke JavaVM end method with user thread

The batch application execution functionality executes interrupt of the java.lang.Thread class for all running user threads, except the following threads:

- User thread, which invoked JavaVM end method

- main thread

The batch application execution functionality executes method cancellation for the main thread that invokes a user thread. If method cancellation is successful, the main thread ends, and then the batch application ends. If an attempt to execute method cancellation fails, JavaVM ends for each batch server.

We do not recommend invoking the JavaVM end method in user threads because an attempt to execute method cancellation.

In both the cases, when the main thread ends, start of next batch application is accepted irrespective of whether a user thread remains.

To Page Top