Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: A JAVA Database Connectivity (JDBC) subsystem includes a connection pool and prepared statement cache, which allows application to interact with a database. The JDBC subsystem can include a profiling component and a statistics monitoring component that maintain profile and statistics information concerning components of JDBC subsystem, such as the connection pool and prepared statement cache. A client application can register a diagnostic callback with the JDBC subsystem, for use with requests from that client application to methods of the JDBC driver being executed.

Abstract: A connection pool can use a credential mapper to map credentials for an application server into a credential to use with the database management system. This can allow objects such as an Enterprise Java Bean to access the database with more specific credentials than the anonymous connection pool connection user name/password.

Abstract: Applications can interact with a database using a JDBC subsystem. The JDBC subsystem includes a connection pool with multiple connections, and parses database requests to produce statements to be sent to a database management system (DBMS). A previously parsed statement can be stored in a prepared statement cache. A profiling component can be used to maintain profile information concerning the connection pool and the prepared statement cache.

Abstract: A multipool can do a callback to an application before switching connection pools.

Abstract: An improved resource pool is provided that provides for dynamic configuration and is comprised of code that is configured to be used for different subsystems, including JDBC, Connector, and JMS subsystems. Pool maintenance, resource object creation and timeout, multiple deque management, and pool state transition features are provided. An application server may include at least one resource pool object, wherein each resource pool object represents a resource pool in the application server. An improved prepared statement cache is also provided that works in conjunction with the resource pool implementation to more effectively provide for prepared statement processing.

Abstract: An improved resource pool is provided that provides for dynamic configuration and is comprised of code that is configured to be used for different subsystems, including JDBC, Connector, and JMS subsystems. Pool maintenance, resource object creation and timeout, multiple deque management, and pool state transition features are provided. An application server may include at least one resource pool object, wherein each resource pool object represents a resource pool in the application server. An improved prepared statement cache is also provided that works in conjunction with the resource pool implementation to more effectively provide for prepared statement processing.

Abstract: Dynamically generating a wrapper object to intercept transmissions between a vendor object and an application program and performs server side tasks. To dynamically generate the wrapper at runtime in memory, the application server receives a vendor class, performs reflection on the vendor class, generates a wrapper class, and creates an instance of the wrapper class. In operation, the dynamically generated wrapper object receives a call placed to a method of the wrapped object, initiates pre-processing tasks to be performed, calls the method on the wrapped object, receives a result from the method invocation against the wrapped object, initiates post-processing tasks to be performed, and transmits the wrapped result back to the application program. The pre-processing tasks may include execution of a pre-invocation handler. The post-processing tasks may include execution of a post-invocation handler.

Abstract: A dynamic generated wrapper object to intercept transmissions between a vendor object and an application program and performs server side tasks. To dynamically generate the wrapper at runtime in memory, the application server receives a vendor class, performs reflection on the vendor class, generates a wrapper class, and creates an instance of the wrapper class. In operation, the dynamically generated wrapper object receives a call placed to a method of the wrapped object, initiates pre-processing tasks to be performed, calls the method on the wrapped object, receives a result from the method invocation against the wrapped object, initiates post-processing tasks to be performed, and transmits the wrapped result back to the application program. The pre-processing tasks may include execution of a pre-invocation handler. The post-processing tasks may include execution of a post-invocation handler.

Abstract: The JDBC data sources configuration can be stored in a JDBC configuration XML. This configuration XML can be converted into Java beans to configure data sources such as basic data sources, connection pools or multipool. Migration can be done by using a administration console tool to update the configuration XML with the new binding variables for the production environment.

Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: A server self health monitor (SHM) system monitors the health of the server it resides on. The health of a server is determined by the health of all of a server's sub-systems and deployed applications. The SHM may make health check inquiries to server sub-systems periodically or based on external trigger events. The sub-systems perform self health checks on themselves and provide sub-system health information to requesting entities such as the SHM. Sub-systems self health updates may be based on internal events such as counters or changes in status or based on external entity requests. Corrective action may be performed upon sub-systems by the SHM depending on their health status or the health status of the server. Corrective action may also be performed by a sub-system upon itself.

Abstract: An improved resource pool is provided that provides for dynamic configuration and is comprised of code that is configured to be used for different subsystems, including JDBC, Connector, and JMS subsystems. Pool maintenance, resource object creation and timeout, multiple deque management, and pool state transition features are provided. An application server may include at least one resource pool object, wherein each resource pool object represents a resource pool in the application server. An improved prepared statement cache is also provided that works in conjunction with the resource pool implementation to more effectively provide for prepared statement processing.

Abstract: An improved resource pool is provided that provides for dynamic configuration and is comprised of code that is configured to be used for different subsystems, including JDBC, Connector, and JMS subsystems. Pool maintenance, resource object creation and timeout, multiple deque management, and pool state transition features are provided. An application server may include at least one resource pool object, wherein each resource pool object represents a resource pool in the application server. An improved prepared statement cache is also provided that works in conjunction with the resource pool implementation to more effectively provide for prepared statement processing.

Abstract: A Node Manager monitors the status of multiple servers. The Node Manager detects server failures, periodically monitors server health status, and performs server maintenance. When the Node Manager detects a server failure, it determines whether or not the server should be restarted. While periodically monitoring servers, the Node Manager may determine how often to trigger a health check, how long to wait for a response, and how to proceed if the server is deemed failed. The Node Manager may be controlled by an Administrative Server directly or by an external administrative agent. An administrative agent may control the Node Manager by interfacing with the Administrative Server. The Node Manager and AS may authenticate each other and encode their communications to each other for increased security.

Abstract: An improved resource pool is provided that provides for dynamic configuration and is comprised of code that is configured to be used for different subsystems, including JDBC, Connector, and JMS subsystems. Pool maintenance, resource object creation and timeout, multiple deque management, and pool state transition features are provided. An application server may include at least one resource pool object, wherein each resource pool object represents a resource pool in the application server. An improved prepared statement cache is also provided that works in conjunction with the resource pool implementation to more effectively provide for prepared statement processing.