Microsoft Technology Licensing, LLC

Chadwin James Mumford

Peter Gvozdjak

Balendran Mugundan

Raghu Ram

Matthew Alban Neerincx

David Bruce Lomet

Quetzalcoatl Bradley

Oleg Ignat

Jimmy Yu Wu

Luiz Fernando Federico Dos Santos

David W Olix

Sapna Daryanomal Jeswani

Luiz F Santos

Zlatko Michailov

Junfeng Dong

Rohan Samuel Lam

Il-Sung Lee

Matt A Neerincx

Matthew A Neerincx

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

Aspects of the subject matter described herein relate to database connectivity behavior. In aspects, an entity seeking to access data that is replicated via instances of a database follows a plan. The plan provides information as to which instance(s) the entity is to attempt to access the data from. The plan may include connection data that indicates parameters the entity is to use in connecting to the instance(s). The plan may also indicate one or more other instances from which the entity may attempt to access the data if the client is not able to access the data from initial instance(s).

Modeling distribution and failover database connectivity behavior

A request for application information can be received from an application running in a process. The application information can be requested from an information repository, and received back from the repository in a first format. The application information can be converted to a second format, and passed to the application in the second format. In addition, the application information can be saved in the second format in a cache in the process. Also, when application information has been cached in response to a request for the information for a first user object, and a subsequent request for the application information for a second user object is received, it can be determined whether the second user object is authorized to access the application information. If so, then the application information can be fetched from the cache and returned for use by the second user object.

Cache for storage and/or retrieval of application information

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

Woodinville, WA, United States of America

Chadwin James Mumford