6.4.1 Processing when starting an application
This subsection describes the application negotiation processing executed when an application starts and the application identifiers used in application negotiation processing.
- Organization of this subsection
(1) Application negotiation processing
With a Web application that uses the database session failover functionality, negotiation processing is executed when you start an application.
With negotiation processing, the following contents are checked:
-
Web applications are matching
-
Settings of each Web application are matching
-
J2EE server settings are matching
-
Database settings are correct
The result of negotiation processing determines whether a Web application will start.
The following table describes the relation between the result of negotiation processing and the Web application states.
- Legend:
-
--: Not applicable
- #
-
For the following confirmation items, if you have set different values in a Web application to be started and the same Web application on another J2EE server, you can select whether to continue or stop the processing of starting a Web application by specifying the webserver.dbsfo.negotiation.high_level parameter in the <configuration> tag of a logical J2EE server (j2ee-server) in the Easy Setup definition file.
-
Upper limit of the number of HttpSession objects
-
Validity of HTTP sessions defined in DD (web.xml)
If other confirmation contents are not matching, Web applications do not start.
If you set to stop the processing of starting a Web application, make sure to specify a valid value (1 or greater) as the upper limit of the number of HttpSession objects.
If an error occurs while accessing the database during negotiation processing, the KDJE34312-W message is output to the message log.
(a) Contents checked in negotiation processing (the database session failover functionality)
This subsection describes the contents checked in negotiation.
-
Web applications are matching
It is determined that Web applications are matching when all confirmation items match. The following table describes the confirmation items.
Table 6‒7: Items used for confirming whether web applications are matching Sr. No.
Confirmation item
1
Application identifier#
2
J2EE application name
3
Web application name (context root name)
# For details on application identifier, see (2) Application identifier.
-
Settings of each Web application are matching
Whether the settings of each replicated Web application are matching is checked for the confirmation items described in the following table.
Table 6‒8: Items used for confirming whether the settings of each Web application are matching Sr. No.
Confirmation item
1
Upper limit of the number of HttpSession objects
2
Maximum size of HTTP session attribute information that you can include in global session information
3
Validity of HTTP sessions defined in DD (web.xml)
4
Extensions that inhibit the database session failover functionality
-
J2EE server settings are matching
Whether the settings of each replicated J2EE server are matching is checked for the confirmation items described in the following table.
Table 6‒9: Items used for confirming whether the settings of each J2EE server are matching Sr. No.
Confirmation item
1
Settings of integrity mode
2
Settings of refer-only requests
3
Settings if pending queues are insufficient when using the functionality for controlling the number of concurrent execution threads
4
Settings of exception when executing the getSession method in the requests targeted for inhibiting the database session failover functionality
-
Database settings are correct
Whether the conditions described in the following table are satisfied is checked.
Table 6‒10: Conditions for checking that the database settings are correct Sr. No.
Condition
1
Required tables exist in the database.
2
Contents of existing table are the contents of the table used for the database session failover functionality.
3
Existing tables are not used in other applications.
(b) Settings of a Web application that are checked in negotiation
First of all, settings of a Web application that succeeds in negotiation processing are stored in the application information table in the database. Stored settings are treated as correct preference information used in negotiation confirmation.
Therefore, if you want to change the settings of a Web application, you must delete the preference information already stored in the database that is related to a Web application targeted to make changes. For details on the procedures for changing the settings, see 6.7 Changing settings related to the database session failover functionality.
(2) Application identifier
The Application identifier is a name used for recognizing clustered Web applications when using the database session failover functionality. By default, the system automatically generates application identifiers.
An application identifier is used in negotiation for checking whether Web applications are matching. Therefore, an application identifier must satisfy the following conditions:
-
An application identifier matches the same Web application that operates on the replicated J2EE servers.
-
An application identifier is a unique value in the system.
If an application identifier, which is automatically generated by the system, does not satisfy a condition, you need to define values that satisfy the conditions. For details on how to define an application identifier, see 6.5 Definitions in cosminexus.xml.
The following subsections describe the rules for automatically generating an application identifier and examples of automatically generated application identifiers.
- Important note
-
If the same application identifier is set to different Web applications, the second Web application fails in negotiation when starting and does not start.
(a) Rules for automatically generating an application identifier
By default, a string based on context root name is automatically set in application identifiers. If an application identifier is automatically generated, the applicable value is output to the message log with the KDJE34302-I message, when starting a Web application.
The following rules are applied when automatically generating an application identifier on the basis of context root name:
-
Delete the forward slash (/) at the beginning.
-
If the length of the string exceeds 16 characters, excluding the forward slash (/) at the beginning, use a string up to 16 characters.
-
If characters, which cannot be used in an application identifier, are used in the context root name, replace the characters with underscores (_).
You can use only alphanumeric characters (A - Z, a - z, and 0 - 9) and underscores (_) in an application identifier. Set values are case-sensitive.
-
In root context, change to ROOT and not to a blank string.
If you apply the rules for automatic generation, an application identifier might not remain unique in the system. In that case, the second Web application, to which the same application identifier is set, fails in negotiation when starting and does not start. Therefore, it is essential to set an application identifier that unique in the system, for Web applications.
(b) Examples of automatically generated application identifiers
The following table shows examples of default application identifiers, which are automatically generated from context root name.
Sr. No. |
Context root name |
Application identifier |
Rules applied when creating |
---|---|---|---|
1 |
/examples |
examples |
Delete the forward slash (/) at the beginning |
2 |
/App01/test1 |
App01_test1 |
|
3 |
/WebApplication_001 |
WebApplication_0 |
|
4 |
/examples/WebApplication |
examples_WebAppl |
|
5 |
/ |
ROOT |
Because it is root context, change to ROOT |