Patent application number | Description | Published |
20110055368 | Connection Pool Use of Runtime Load Balancing Service Performance Advisories - 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. | 03-03-2011 |
20110238655 | SYSTEM AND METHOD FOR PROVIDING HIGHLY AVAILABLE DATABASE PERFORMANCE - 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. | 09-29-2011 |
20130066837 | RECOVERING STATEFUL READ-ONLY DATABASE SESSIONS - 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. | 03-14-2013 |
20130066948 | IDEMPOTENCE FOR DATABASE TRANSACTIONS - 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. | 03-14-2013 |
20130066949 | IDEMPOTENCE FOR DATABASE TRANSACTIONS - 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. | 03-14-2013 |
20130066952 | PRESERVING SERVER-CLIENT SESSION CONTEXT - 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. | 03-14-2013 |
20130066955 | MASKING DATABASE OUTAGES FROM CLIENTS AND APPLICATIONS - 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. | 03-14-2013 |
20130297566 | RECOVERING STATEFUL READ-ONLY DATABASE SESSIONS - 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. | 11-07-2013 |