Microsoft Technology Licensing, LLC

Other

Tarkan Sevilmis

Arshish C Kapadia

Alexander Hopmann

Peter Adam Outcalt

Nikita Voronkov

Viktoriya Taranov

Daniel Blood

Siddharth Rajendra Shah

Tittu Jose

Bhavesh Anil Doshi

Ramanathan Somasundaram

Artsiom Kokhan

Ryan Yandle

Targo Tennisberg

Mohammed Nazeeruddin

Hardik V Shah

Sreekanth Lingannapeta

Maxim Lukiyanov

Marius Bunescu

Gheorghita Irimescu

Janak Madhusudan Agarwal

Stephen John Clark

Jason Matthew Cahill

Eric B Fox

Rolando Jimenez Salgado

Karthik Kalyanaraman

David Koronthaly

Michael Thomas McLean

Marc Keith Windle

Erick Raymundo Lerma

Zach Rosenfield

Kshamta Jerath

Doron Bar-Caspi

Sundar Paranthaman

Kaushik Raj

Ricardo Prates De Oliveira

Colin Daniel Eugene Jeanne

Nazeeruddin Mohammed

Andre Makram

Sid R Shah

A secondary location is configured as a recovery service for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the secondary location is automatically updated to reflect a current state of the primary location that is actively servicing user load. Content changes to the primary location are automatically reflected to the secondary location. System changes applied to the primary location are automatically applied to the secondary location. For example, removing/adding machines, updating machine/role assignments, removing adding/database are automatically applied to the secondary location such that the secondary location substantially mirrors the primary location. After a failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Automatic configuration of a recovery service

Systems, methods, and software for management of partitioned data storage spaces is provided herein. An exemplary method includes storing sets of structured data records among partitioned data storage spaces, with data fields of the structured data records correlated among the sets by relational associations. The method includes, in a data center that receives change actions related to the structured data records, selectively placing the change actions into a plurality of change feeds, where the change feeds can be commutatively executed in parallel to implement the change actions. The method further includes implementing the change actions and propagating replication data comprising the change actions in the plurality of change feeds.

Replication of structured data records among partitioned data storage spaces

An intelligent conflict detection system. The system provides semantic expression of edits and history-aware conflict detection in a large-scale service allowing multiple users to simultaneously work with the same document, which may result in conflicting edits. When submitted, changes to a version of a document are compared to all versions of the document created since the document was sourced. Edits to documents are expressed as intents describing the changes in terms of an action and object of that action based on a characteristic of the data being edited. Comparing the intent of current edits against the historical intent of the edits made in prior versions originating from the same source document allows the system to intelligently assess whether the edits are in conflict. History-aware semantic analysis results in users being prompted less frequently to resolve conflicts, which improves the user experience.

Intelligent conflict detection and semantic expression of document edits

A consistent user view system. The system incorporates any changes made by a user in any views shown to that user even when the changes have not propagated to the partitions supplying the view. The system separates the authority for edits from the replicated storage allowing efficient transactions and linear scalability. Documents are read from view-based partitions of a store. Document writes are written to a document-specific partition in a journal and applied to the store. The system stores a copy of pending changes in a user-specific partition. When a user requests a view, the system checks that user's cache for any pending changes applicable to the view. If any applicable changes are found, the changes are applied before showing the view to the user. Pending changes that have been successfully applied to the store are trimmed from the user-specific partition to free up resources.

Consistent views of partitioned data in eventually consistent systems

Systems, methods, and software for management of partitioned data storage spaces are provided herein. An exemplary method includes storing sets of structured data records among partitioned data storage spaces, with data fields of the structured data records correlated among the sets by relational associations. The method includes maintaining data fields in a first set of structured data records, the data fields comprising promoted data fields that reference properties of data fields of a second set of structured data records. Responsive to an update to a data field of a first structured data record, the method includes determining if the update relates to a promoted data field, implementing a portion of the update in the second set of structured data records, and propagating the update to associated promoted data fields in the first set of structured data records along with any intervening changes received for the associated promoted data fields.

Promoted properties in relational structured data

Systems, methods, and software for management of partitioned data storage spaces is provided herein. An exemplary method includes storing sets of structured data records among partitioned data storage spaces, with data fields of the structured data records correlated among the sets by relational associations. The method includes receiving a change action related to a selected structured data record, and responsive to the change action, scheduling execution of the change action in a reminder index. The method includes executing the change action according to at least scheduling indicated by the reminder index.

Reminder processing of structured data records among partitioned data storage spaces

A scalable eventual consistency system. The system uses logical document journaling to provide eventual consistency across partitions in a large-scale service. The system allows for transactional edits to massively interconnected graphs of documents through parallelization without sacrificing linear scalability. The system separates the authority for edits from the replicated storage allowing efficient transactions and linear scalability. All document writes are written to document-specific partitions in a journal where they are queued until the changes are propagated to view-based partitions of a store. By continually checking the journal and attempting to replicate any pending document writes to the store, the system provides eventual consistency without complicated synchronization mechanisms. The system models membership and containment relationships between documents in manner allowing document writes ultimately impacting more than one document to be efficiently handled through the journal as an edit to a single document.

Scalable eventual consistency system using logical document journaling

When a software component is starting, such as but not limited to a task or a subtask, the component pushes its identification (ID) onto a stack. The component executes its other instructions. If the component completes its instructions so that it can terminate normally, it pops the stack, which removes its ID from the stack. If the component fails, such as by not being able to complete its instructions, it will not be able to pop the stack so its ID will remain in the stack. Another software process can read the IDs in the stack to identify which components have failed and can automatically take a specified action, such as by sending an email message to, sending a text message to, or calling by telephone, a person or persons responsible for that software component.

Failure mode identification and reporting

Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Replaying jobs at a secondary location of a service

When a software component is starting (), such as but not limited to a task or a subtask, the component pushes () its identification (ID) onto a stack. The component then executes () its other instructions. If the component completes its instructions so that it can terminate normally (), then it pops () the stack, which removes its ID from the stack. If the component fails, such as by not being able to complete its instructions, then it will not be able to pop the stack so its ID will remain in the stack. Another software process can then read the IDs in the stack to identify () which components have failed and can automatically take a specified action (), such as by sending an email message to, sending a text message to, or calling by telephone, a person or persons responsible for that software component.

Growing community of inventors

Redmond, WA, United States of America

Tarkan Sevilmis