Abstract: Methods, devices, and computer-readable media are provided for restoring state that was built up on a first session between a first server instance and a client to a second session between a second server instance and the client. Non-transactional session state that existed for the first session is preserved by repeating non-transactional commands in the second session. Transactions are executed in the second session when the transactions did not complete in the first session. The first server instance sends, to the client in the first session, information to maintain for a possible replay of commands that were sent in a request to the first server instance for execution in the first session. If the first session becomes unavailable, the maintained information may be used by the second server instance to restore the database session, masking the outage from users, applications, and clients.

Abstract: Runtime connection load balancing of work across connections to a clustered computing system involves the routing of requests for a service, based on the current operational performance of each of the instances that offer the service. A connection is selected from an identified connection pool, to connect to an instance that provides the service for routing a work request. The operational performance of the instances may be represented by performance information that characterizes the response time and/or the throughput of the service that is provided by a particular instance on a respective node of the system, and is relative to other instances that offer the same service.

Abstract: A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable due to a planned or unplanned recoverable error. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state, which was exposed to the client from the previous database session, on the new database session. The process masks the outage from the application.

Abstract: A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state on the new database session. The process masks the outage from the application.

Abstract: Methods, devices, and storage media are provided for preserving the context of a server-client session. A server generates an initial context and a context for each user command executed in a first session and sends context to a client with the return for each command. The context describes software, session state, returned data, and/or hardware characteristics of a server-side environment for the first session. The client receives and stores the context with each user command. Upon determining that the database session should be rebuilt in the second session, the client sends initial context. A server for the second session receives the initial context and determines whether commands should be replayed in the second session. If commands are replayed, the server validates that server environment and client-visible results for each command in the second session match that from execution in the first session using the context for that command.

Abstract: A method, machine, and computer-readable medium is provided for managing transactional sets of commands sent from a client to a server for execution. A first server reports logical identifiers that identify transactional sets of commands to a client. The first server commits information about a set of commands to indicate that the set has committed. A second server receives, from the client, a request that identifies the set based on the logical identifier that the client had received. The second server determines whether the request identified the latest set received for execution in a corresponding session and whether any transactions in the set have not committed. If any transaction has not committed, the second server enforces uncommitted state of the identified set by blocking completion of the identified set issued in the first session. The identified set may then be executed in the second session without risk of duplication.

Abstract: Methods, devices, and computer-readable media are provided for restoring state that was built up on a first session between a first server instance and a client to a second session between a second server instance and the client. Non-transactional session state that existed for the first session is preserved by repeating non-transactional commands in the second session. Transactions are executed in the second session when the transactions did not complete in the first session. The first server instance sends, to the client in the first session, information to maintain for a possible replay of commands that were sent in a request to the first server instance for execution in the first session. If the first session becomes unavailable, the maintained information may be used by the second server instance to restore the database session, masking the outage from users, applications, and clients.

Abstract: A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state on the new database session. The process masks the outage from the application.

Abstract: A method, machine, and computer-readable medium is provided for managing transactional sets of commands sent from a client to a server for execution. A first server reports logical identifiers that identify transactional sets of commands to a client. The first server commits information about a set of commands to indicate that the set has committed. A second server receives, from the client, a request that identifies the set based on the logical identifier that the client had received. The second server determines whether the request identified the latest set received for execution in a corresponding session and whether any transactions in the set have not committed. If any transaction has not committed, the second server enforces uncommitted state of the identified set by blocking completion of the identified set issued in the first session. The identified set may then be executed in the second session without risk of duplication.

Abstract: A system and method for enabling a second database instance to more quickly process a request to execute a database statement that has previously been executed by a first database instance is described. In one embodiment, the method involves sending the database statement from the first database instance to the second database instance, and generating by the second database instance one or more structures needed to prepare the statement for execution, such as a parse tree and an execution plan for the statement. If at some point in the future, the second database instance receives a request to execute the same statement, the above structures can be used for execution, thereby eliminating the need for one or more potentially time-consuming operations, such as generation of a parse tree or execution plan for the statement.

Abstract: A system and method for enabling a second database instance to more quickly process a request to execute a database statement that has previously been executed by a first database instance is described. In one embodiment, the method involves sending the database statement from the first database instance to the second database instance, and generating by the second database instance one or more structures needed to prepare the statement for execution, such as a parse tree and an execution plan for the statement. If at some point in the future, the second database instance receives a request to execute the same statement, the above structures can be used for execution, thereby eliminating the need for one or more potentially time-consuming operations, such as generation of a parse tree or execution plan for the statement.

Abstract: A system and method for enabling a second database instance to more quickly process a request to execute a database statement that has previously been executed by a first database instance is described. In one embodiment, the method involves sending the database statement from the first database instance to the second database instance, and generating by the second database instance one or more structures needed to prepare the statement for execution, such as a parse tree and an execution plan for the statement. If at some point in the future, the second database instance receives a request to execute the same statement, the above structures can be used for execution, thereby eliminating the need for one or more potentially time-consuming operations, such as generation of a parse tree or execution plan for the statement.

Abstract: Runtime connection load balancing of work across connections to a clustered computing system involves the routing of requests for a service, based on the current operational performance of each of the instances that offer the service. A connection is selected from an identified connection pool, to connect to an instance that provides the service for routing a work request. The operational performance of the instances may be represented by performance information that characterizes the response time and/or the throughput of the service that is provided by a particular instance on a respective node of the system, and is relative to other instances that offer the same service.

Abstract: Runtime connection load balancing of work across connections to a clustered computing system involves the routing of requests for a service, based on the current operational performance of each of the instances that offer the service. A connection is selected from an identified connection pool, to connect to an instance that provides the service for routing a work request. The operational performance of the instances may be represented by performance information that characterizes the response time and/or the throughput of the service that is provided by a particular instance on a respective node of the system, and is relative to other instances that offer the same service.

Abstract: A system and method for detecting termination of an application, such as a database instance, that uses locks is described. A holding child process is started from a parent process. The holding child process connects to a monitored application instance, acquires an exclusive lock on the monitored application instance and returns a ready signal upon successfully acquiring the exclusive lock. A waiting child process is started from the parent process subsequent to the holding child process. The holding child process connects to the monitored application instance, blocks on the exclusive lock on the monitored application instance and returns a result signal upon at least one of acquiring the exclusive lock and clearing the block on the exclusive lock. The return signal is processed at the parent process. Using locks provides immediate detection that the application has terminated. Methods for blocking against the application are also described.

Abstract: A system and method for providing cooperative resource groups for high availability applications, such as cluster databases, is described. A cluster framework, including a plurality of nodes, is built. A plurality of cooperative resource groups is formed, each including a logical network address, at least one monitor and an application providing services and externally accessed using the logical network address. A plurality of resources is structured, each including a cluster service supporting the services provided by each application. A preferred node for execution is designated for each cooperative resource group and one or more possible nodes are provided as standby nodes for each other cooperative resource group. The services are restarted on a surviving node off a critical path of the preferred node upon an unavailability of the preferred node, while the logical network address is kept available on each possible node for the cooperative resource group.

Abstract: A system and method for detecting a failure of a first process is disclosed. According to one aspect, a first connection is established between a first process and a second process. A monitoring mechanism monitors the status of the first process to detect whether the first process has failed. In response to determining that the first process has failed, the monitoring mechanism causes an out-of-band message to be sent to the second process.

Abstract: A system and method for detecting termination of an application, such as a database instance, that uses locks is described. A holding child process is started from a parent process. The holding child process connects to a monitored application instance, acquires an exclusive lock on the monitored application instance and returns a ready signal upon successfully acquiring the exclusive lock. A waiting child process is started from the parent process subsequent to the holding child process. The holding child process connects to the monitored application instance, blocks on the exclusive lock on the monitored application instance and returns a result signal upon at least one of acquiring the exclusive lock and clearing the block on the exclusive lock. The return signal is processed at the parent process. Using locks provides immediate detection that the application has terminated. Methods for blocking against the application are also described.

Abstract: A system and method for enabling a second database instance to more quickly process a request to execute a database statement that has previously been executed by a first database instance is described. In one embodiment, the method involves sending the database statement from the first database instance to the second database instance, and generating by the second database instance one or more structures needed to prepare the statement for execution, such as a parse tree and an execution plan for the statement. If at some point in the future, the second database instance receives a request to execute the same statement, the above structures can be used for execution, thereby eliminating the need for one or more potentially time-consuming operations, such as generation of a parse tree or execution plan for the statement.