Abstract: A client-server database system enables persistent client-server database sessions, without modification to a client-side application, a database system, or native client-side database drivers. The client is implemented with a driver manager to facilitate communication between the native database drivers and the database application. The driver manager wraps the native drivers, intercepting queries passed from the database application to the database drivers. The driver manager modifies the queries to form modified queries that direct the database server to render result sets produced from processing the queries persistent at the database server. Upon recovery following a server crash, the driver manager directs the drivers to reestablish a connection with the database server. The driver manager then finds the persistent result set table and, using logged data, returns to the same operation on the result set table just prior to the crash.

Abstract: The subject invention pertains to data store corruption recovery. More specifically, the invention concerns systems and methods for identifying corrupt data in a manner that prevents de-committing or removal of valid or consistent transactions from a database. This can be accomplished at least in part by logging the identities of data items that a transaction reads. Furthermore, the subject invention provides for employment of a multi-version (or transaction-time) database to reduce significantly reduce any down time or database unavailability caused by a corrupt transaction and associated corrupt data items. Accordingly, no backups need to be installed and only updates by the original corrupt transaction and transactions that read corrupt data need to be de-committed or removed.

Abstract: Persistent components are provided across both process and server failures, without the application programmer needing take actions for component recoverability. Application interactions with a stateful component are transparently intercepted and stably logged to persistent storage. A “virtual” component isolates an application from component failures, permitting the mapping of a component to an arbitrary “physical” component. Component failures are detected and masked from the application. A virtual component is re-mapped to a new physical component, and the operations required to recreate a component and reinstall state up to the point of the last logged interaction is replayed from the log automatically.

Abstract: A technique is described for guaranteeing recovery in a computer system comprising of recovery contracts with a plurality of obligations for a message exchange between a first component and a second component. Three forms of contract are described, governing interactions between three types of components. Each contract is bilateral, i.e. between a first component and a second component. The first and second components have mutual agreement on when the contract will be released to facilitate log truncation, and independent and/or autonomous recovery.

Abstract: A system, method and computer-readable medium for optimizing recovery logging is provided. A calling component stably logs a message from a called component only when sending a second message or sending a second message after a log force that writes the return message from the first message to the stable log. The called component stably logs its return message before the return message is sent.

Abstract: Persistent components are provided across both process and server failures, without the application programmer needing take actions for component recoverability. Application interactions with a stateful component are transparently intercepted and stably logged to persistent storage. A “virtual” component isolates an application from component failures, permitting the mapping of a component to an arbitrary “physical” component. Component failures are detected and masked from the application. A virtual component is re-mapped to a new physical component, and the operations required to recreate a component and reinstall state up to the point of the last logged interaction is replayed from the log automatically.

Abstract: A client-server database system enables persistent client-server database sessions, without modification to a client-side application, a database system, or native client-side database drivers. The client is implemented with a driver manager to facilitate communication between the native database drivers and the database application. The driver manager wraps the native drivers, intercepting queries passed from the database application to the database drivers. The driver manager modifies the queries to form modified queries that direct the database server to render result sets produced from processing the queries persistent at the database server. Upon recovery following a server crash, the driver manager directs the drivers to reestablish a connection with the database server. The driver manager then finds the persistent result set table and, using logged data, returns to the same operation on the result set table just prior to the crash.

Abstract: A technique is described for guaranteeing recovery in a computer system comprising of recovery contracts with a plurality of obligations for a message exchange between a first component and a second component. Three forms of contract are described, governing interactions between three types of components. Each contract is bilateral, i.e. between a first component and a second component. The first and second components have mutual agreement on when the contract will be released to facilitate log truncation, and independent and/or autonomous recovery.

Abstract: A client-server database system enables persistent client-server database sessions, without modification to a client-side application, a database system, or native client-side database drivers. The client is implemented with a driver manager to facilitate communication between the native database drivers and the database application. The driver manager wraps the native drivers, intercepting queries passed from the database application to the database drivers. The driver manager modifies the queries to form modified queries that direct the database server to render result sets produced from processing the queries persistent at the database server. Upon recovery following a server crash, the driver manager directs the drivers to reestablish a connection with the database server. The driver manager then finds the persistent result set table and, using logged data, returns to the same operation on the result set table just prior to the crash.

Abstract: A client-server database system enables persistent client-server database sessions, without modification to a client-side application, a database system, or native client-side database drivers. The client is implemented with a driver manager to facilitate communication between the native database drivers and the database application. The driver manager wraps the native drivers, intercepting queries passed from the database application to the database drivers. The driver manager modifies the queries to form modified queries that direct the database server to render result sets produced from processing the queries persistent at the database server. Upon recovery following a server crash, the driver manager directs the drivers to reestablish a connection with the database server. The driver manager then finds the persistent result set table and, using logged data, returns to the same operation on the result set table just prior to the crash.