Microsoft Technology Licensing, LLC

Balendran Mugundan

Chadwin James Mumford

Peter Gvozdjak

Raghu Ram

David Bruce Lomet

Quetzalcoatl Bradley

Matthew Alban Neerincx

Oleg Ignat

Jimmy Yu Wu

Luiz F Santos

Luiz Fernando Federico Dos Santos

Sapna Daryanomal Jeswani

David W Olix

Affan Arshad Dar

Rajeev Mandayam Vokkarne

Anush Prabhu Ramachandran

Raimundo Robledo Pontes Filho

Matthew A Neerincx

Chadwin J Mumford

Described herein is a device (e.g., IoT device) having bootstrap code that communicates with a secure global registry (e.g., private distributed shared blockchain database). The bootstrap code of the device uses a globally unique device identifier of the device to the secure global registry. The bootstrap code receives information from the secure global registry which the bootstrap code uses to obtain information to connect to a cloud-based endpoint. The bootstrap code can download an appropriate software development kit (SDK) associated with the particular cloud based, at least in part, upon the received information. The device can be registered in the secure global registry by creating a globally unique identifier for the device. An initial entry can be created in the secure global registry comprising the globally unique identifier, with the secure global registry stores current cloud-based endpoint information, if any, for the device.

Discovery and matching of internet of things (IoT) devices and services using a secure global registry

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

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.

Extending types hosted in database to other platforms

Aspects of the subject matter described herein relate to buffering database server response data. In aspects, a database driver receives a request for data from a requester such as an application. Based on the request and information associated with a query, the database driver determines whether the requester is allowed to obtain data that has been previously buffered. If the database driver determines that the requester is not allowed to obtain data that has been previously buffered, the database driver indicates that blocks corresponding to the data may be freed. The database driver obtains new blocks from the database when they are needed. The database driver may determine whether to free blocks depending on a mode in which the blocks are accessed. When blocks are requested in a stream mode, they may be discarded once provided to a requester unless a bookmark has been set.

Growing community of inventors

Redmond, WA, United States of America

Balendran Mugundan