To optimize overall system workload into logical segments, JD Edwards EnterpriseOne assigns processing tasks to various kernel processes running on a JD Edwards EnterpriseOne Enterprise Server. These kernels use static and dynamic database connections at process initiation and maintains those connections to a database for the entire EnterpriseOne process life cycle. In case of any interruption to the database connection or connection sessions therein, the connection or session must be recovered or restarted. Understanding how static and dynamic EnterpriseOne database connections work and their impact on the JD Edwards system is important.
The JDBC interface of the EnterpriseOne HTML Server is a single-process connection to a database; on the other hand, multiple connections are made through the Enterprise Server kernel processes using JD Edwards EnterpriseOne CallObject kernels. The EnterpriseOne HTML Server depends on communication to the Enterprise Server Security kernel for authentication and other security process requests to function properly; thus loss of database connections on the Enterprise Server Security and Metadata kernel processes has a subsequent downstream effect on the EnterpriseOne HTML Server performance.
Kernels that are classified as static use a bootstrap login to establish the connection. This means that the login credentials are stored in and read from the jde.ini of the Enterprise Server. This is called the login environment. Unlike dynamic connections, a login to a static kernel is never logged out during the process lifetime. Again, this is because unlike dynamic connections, a static login environment is not subject to timeouts due to inactivity or logouts. Under normal conditions, these static kernels are only restarted when the Enterprise Server is restarted. Otherwise static kernels can only be restarted by manually killing the process and restarting it.
Among the key functions of a static kernel are database connections. If the connection to the database is temporarily lost for any reason such as network unavailability, the kernels have fault-tolerant logic to retry the connection for up to 75 seconds reusing the same connection. If the connection cannot be reestablished within 75 seconds, the process is failed. As previously mentioned, an entire static process can only be restarted by either restarting the Enterprise Server or by manually killing and restarting the process.
In order to avoid the situation where the database connection within a kernel process are in a failed state (timed out for more than 75 seconds) that is unknown to the system, functionality is added to Server Manager to refresh those database connections in static environments either periodically or on demand. This functionality is only available to an Admin user for Server Manager. When invoked, this function refreshes each static kernel for all database connections. The list of such static kernels may change from release to release, so it is not important that they be individually listed. Additionally, a static environment type, such as Security, may include multiple kernels of the same type. In such cases, this function will refresh each kernel in a static environment type.
It is important to note that the intent of a "refresh" is primarily to reestablish the database connections without resorting to a destructive "kill" action. As such, a refresh preserves the other logical states in the kernel and the kernel maintains the same internal functional state as it was prior to the refresh of the database connections.
One exception to the static kernel model is the Workflow kernel. This kernel can only free expired environments, that is, environments that have timed out. If a workflow environment is still active, it will not be forcibly freed by the refresh process.
Automatic Kernel Refresh
Note: The implementation of Automatic Kernel Refresh is only compatible with Oracle databases that are using multi node Real Time Application Cluster (RAC). This is because the process depends on the availability of a functioning node, which is not the case in a single node database in the event of a failure due to such factors are hardware or network issues. Multi node RAC environments are typically available for Oracle Autonomous Database (ADB) implementations.
In order to avoid disrupting normal processing, the JD Edwards kernel automatic kernel refresh logic only executes on an idle kernel process. If a kernel uses multiple threads, the logic will wait to refresh until all threads are idle. Basically a refresh involves a logout and a bootstrap login which reestablishes the database connections either using existing connections or establishing new connections; thus ensuring the connections are valid. This logout/login process does not kill a process or establish a new process - it reuses the existing process with reestablished database connections and returns the kernel to its prior state.
For implementation details, refer to the following section entitled: Using Automatic Kernel Refresh.
On-Demand Manual Kernel Refresh
You can use the Refresh Environments button to force a refresh for all static environments and CallObject kernels (which are dynamic kernels).
For static environments, the refresh will occur regardless of whether the kernel is idle. However, the refresh will wait until all threads of the kernel are complete. As with the automatic kernel refresh, the refresh does not kill a process or establish a new process - it reuses the existing process with reestablished database connections.
For CallObject kernels, these are dynamic kernels which are created by actual or programmatic user logins. Clicking the Refresh Environment button flags these kernels for recycling. In this case, recycling means the system will attempt to terminate a CallObject kernel gracefully, which means when all users of the CallObject kernel are either voluntarily logged out or forcibly logged out by an inactivity timeout (typically either 6 or 12 hours, for inactive or forced logouts, respectively). New CallObject kernels are created upon user login. This reestablishes the database connections for the kernel.
For example, in Production environments you might use the on-demand function if you are performing database patching during a planned maintenance window. In this case you would not be constrained by a short loss in system availability.
For implementation details, refer to the following section entitled: Using On-Demand Kernel Refresh.
https://docs.oracle.com/en/applications/jd-edwards/cross-product/9.2/eoism/understanding-kernel-refresh.html#u30154786
