Microsoft Technology Licensing, LLC

Peter Gvozdjak

Chadwin James Mumford

Balendran Mugundan

Raghu Ram

Matthew Alban Neerincx

David Bruce Lomet

Quetzalcoatl Bradley

Oleg Ignat

Luiz F Santos

Luiz Fernando Federico Dos Santos

Jimmy Yu Wu

Sapna Daryanomal Jeswani

David W Olix

Junfeng Dong

Il-Sung Lee

Rohan Samuel Lam

Matthew A Neerincx

Chadwin J Mumford

Systems and methods are described that facilitate idempotent execution of commands generated by a client for execution by a database server. Each command transmitted to the server includes a command ID generated by the client. The server attempts to execute each command and subsequently stores the command ID associated therewith in a repository along with an indication of whether the command executed successfully. When a new command is received by the server, it determines if the command ID associated therewith has already been stored in the repository. If the command ID associated with the new command has not already been stored in the repository, then the server executes the new command. If the command ID associated with the new command has already been stored in the repository and a previously-received command associated with the command ID has been executed successfully, then the server will not execute the new command.

Idempotent command execution

Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Automatic data request recovery after session failure

A database server includes logic that is operable to monitor and analyze at least events occurring within an environment of the database server and/or execution errors generated by the database server in order to detect whether a problem condition exists. The database server further includes logic that is operable to send one or more commands to a database driver of a client that is communicatively connected to the database server, the one or more commands specifying one or more actions to be taken by the database driver in response to the existence of the problem condition. The database driver includes logic that is operable to receive the one or more commands from the database server and logic that is operable to cause the one or more commands to be executed.

Smart error recovery for database applications

Techniques for recovering from session failures between clients and database servers are described herein. A first session may be established between a client and a first database server to handle a database query for the client. A request for data associated with the first session may be received by the first database server from the client, and the data retrieved. Prior to responding to the request, the data is spooled to a first session state stored in a repository made accessible by at least one computing device. The computing device(s) controls access to session states in the repository that correspond to sessions between clients and database servers. The computing device(s) enables sessions to be reestablished between the clients and database servers by accessing data of the session states in the repository and transmitting the data in response to messages received from the database servers containing session identifiers.

A first computer utilizes a logical connection with a second computer. The logical connection comprises multiple physical network connections using multiple physical network devices on the first computer. Two or more of the physical network devices of a logical connection are used to transfer packets of a single data transfer such as a database request or response. A logical connection can include a single physical network device on the second computer creating a one-to-many logical connection or may also include multiple physical network devices on the second computer creating a many-to-many logical connection.

Maximizing data transfer through multiple network devices

Systems and methods are described that establish and maintain a virtual session between a client and one or more database servers. A database server establishes a first session with a client wherein establishing the virtual session with the client comprises associating a virtual session identifier (ID) with the first session, generates state information in association with the first session, and stores the state information in a repository in association with the virtual session ID. After the first session fails, a same or different database server establishes a second session with the client wherein establishing the second session with the client comprises receiving the virtual session ID from the client, accesses the state information that was stored in the repository in association with the virtual session ID, and associates the state information with the second session.

Virtual session management and reestablishment

Aspects of the subject matter described herein relate to database access. In aspects, a request for access to a database is received at a node of a database cluster. Also received at the node is an intent associated with the request. If the intent is to potentially write to the database, a primary instance of the database services the request. If the intent is to read from but not write to the database, an identifier of a secondary instance of the database is sent to the requestor for use in accessing the database.

Discovery and client routing to database nodes

Systems and methodologies that enhance a Tabular Data Stream (TDS) protocol by enabling efficient transmission of a row(s) with null columns(s). An identification component employs a bit map that can be positioned at beginning of a row, to indicate to the receiving side (e.g., a client) columns that are to be sent. Accordingly, by distinguishing columns that are null from columns that are not null&#x2014;followed by sending columns that are not null&#x2014;transmission resources can be effectively employed.

Compressing null columns in rows of the tabular data stream protocol

Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server, and a transaction may be opened to process a plurality of database commands. One or more commands associated with the transaction may be received from the client at the database server. Each received command has an associated command identifier. A transaction log stores the command identifier associated with each received command and indicates whether each received command has been successfully executed at the database server. After a session failure, the session is reestablished, and a command identifier for a further command is received from the client. If the command identifier associated with the further command is determined to have been stored in the transaction log, the command does not need to be executed, and the transaction may continue.

Automatic transaction retry after session failure

A first computer establishes a logical connection to a second computer for requesting and/or receiving data from a database. A logical connection is independent of the underlying physical network connection used to connect to the database. A context identifier is stored by both computers to enable the context of a logical connection to be persisted between switches from one physical network connection to another within the logical connection thus enabling database transfers to be continued on a second physical network connection when a failure in a first physical network connection occurs.

Transparent database connection reconnect

Aspects of the subject matter described herein relate to extending types hosted in a database to other platforms. In aspects, a database may store objects according to a one type system while an application accessing the database may store objects according to another type system. To allow the application to understand the types, a mapping mechanism may be employed that maps from the types of type system of the database to types of a type system of the application. The mapping mechanism may utilize metadata associated with the data in mapping between types. In conjunction with mapping a source type to a target type, a target object may be instantiated and populated with properties of a source object of the source type.

Growing community of inventors

Bellevue, WA, United States of America

Peter Gvozdjak