6.4.1 Processing when starting an application

(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.

(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.