Microsoft Technology Licensing, LLC

Yunxin Wu

Lev Novik

Irena Hudis

Tomas Talius

Shaoyu Zhou

Douglas Brian Terry

Ashish B Shah

John Edward Gallardo

Alan Geoffrey Boshier

Tudor M Trufinescu

Balan Sethu Raman

Hanumantha Rao Kodavalla

Michael Ray Clark

Robin Dhananjay Dhamankar

Martin J Sleeman

Darshatkumar A Shah

Vasile Paraschiv

Vivek Jawahir Jhaveri

Sanjay Anand

Vishal Kathuria

Siva Muhunthan

Rajesh M Rao

Muhunthan Sivapragasam

Okechukwu C Echeruo

Jingxiao Wu

Don Cao

Ann Tang

Jeremie E Sartor

Jin He

Mark Scurrell

Aspects of the subject matter described herein relate to versioning for databases. In aspects, two or more users may share the same version of data, such as a report, in a database. One of the users may seek to update the data. In response to a request from the user, a new version of the data is created. For data that is not updated via the request, the new version shares data with the previous version, thus saving space. For data this is updated, new segments within the database are created to store the updated data. Each user is allowed to access the data without blocking other users accessing the data.

Optimistic versioning concurrency scheme for database streams

Embodiments are directed to efficiently routing data requests from a plurality of tenants and to using smart routing to limit service denials. In an embodiment, a gateway node receives data requests from a tenant subscriber requesting data for an indicated service. The gateway node determines which server node the received data requests are to be routed to. The determination evaluates various criteria associated with the data request. The gateway node queries the determined server node to determine the health of the server nodes and receives a reply from the determined server node indicating the server node's current operating status. The gateway node also, based on the determined server node's reply, routes the received data requests to the determined server node, according to the evaluated criteria.

Efficiently isolating malicious data requests

Embodiments are directed to providing schedule-based processing using web service on-demand message handling threads and to managing processing threads based on estimated future workload. In an embodiment, a web service platform receives a message from a client that is specified for schedule-based, background handling. The web service platform includes an on-demand message handling service with processing threads that are configured to perform on-demand message processing. The web service platform loads the on-demand message handling service including the on-demand message handling threads. The web service platform implements the on-demand message handling service's threads to perform background processing on the received client message. The client messages specified for background handling are thus handled as service-initiated on-demand tasks.

Architecture for providing on-demand and background processing

Various embodiments of the present invention are directed to synchronization utilizing one or more optimizations through the utilization of metadata. For several embodiments of the present invention, one method for optimizing synchronization is to reduce the overhead required for said synchronization by having each peer only tracking changes for itself and other peers within its change community (or communities) (a.k.a., 'Intra-Community-Only Change Tracking Optimization'). For certain embodiments of the present invention, another method for optimizing synchronization is to not create synchronization overhead until required. For numerous embodiments of the present invention, yet another method for optimizing synchronization is to minimize redundant use of a partner's unique global ID&#x2014;a large and cumbersome number&#x2014;and to instead maintain a table that cross-references each partner (and its unique global ID) with a smaller and much less cumbersome partner key.

Systems and methods for the utilization of metadata for synchronization optimization

Tombstones can be removed from a data store without data corruption. Tombstones placed into a forgotten knowledge list can be compared against each other and/or items in a tombstone table, and deleted when tombstones representing subsequently deleted items are extant. Also, creation database version information can be kept along with database items, and databases can record database version information when they synchronize. If a synchronizing database discovers an item that it does not have, but the creation database version information associated with the item reflects that the synchronizing database 'should' have the item, then it can be inferred that the item was subsequently deleted, and item resurrection can be prevented.

Multi-master database synchronization without loss of convergence

Update-delete conflicts detected during synchronization can be resolved in favor of the update or the deletion. Resolving the conflict in favor of the deletion results in the entity deleted on one replica being deleted on all selected replicas. Resolving the conflict in favor of the update results in the updated entity, which includes an entity moved from one hierarchy to another, being replicated on all selected replicas. To resolve the conflict in favor of the update, the deletion is treated as though it were reported erroneously. The deleted entity is resurrected in the form of the updated entity. Change version information is maintained in all replicas. Update-delete conflicts are resolvable in accordance with various resolution policies such as the update wins, deletion wins, changes occurring on a particular device wins, and most recent event wins, for example.

Resolving update-delete conflicts

Disclosed are systems and methods pertaining to data synchronization and move handling support. In particular, a move log is maintained that identifies data that has moved in, out, and within a synchronization scope. Furthermore, the log comprises times associated with when data moves in and out of the synchronization scope. Systems and methods can interact easily with the generated and updated move log to facilitate determining data versions and identifying new data that may need to be synchronized.

Synchronization move support systems and methods

A system and method for synchronizing a database having metadata and raw data. Metadata may be fully synchronized between two systems, with copies stored on both systems. Raw data may be selectively synchronized, so that a client system need not store all of the raw data locally. When disconnected, the client system may identify certain portions of the raw data to store locally, and such data may be synchronized when reconnected to a server system.

Ghosted synchronization

Systems and methods for synchronizing data stores. A framework including a sync runtime enables consistent and manageable synchronization between a data store and multiple, diverse back end data stores. The sync runtime provides services such as change enumeration, conflict detection, metadata management, item ID matching, sync interruptability, and the like that are accessible to configurable adapters over an application programming interface. Each synchronizing data store can uses a sync controller to initialize an adapter that can access the services provided by the sync runtime. The sync controller can use a profile to configure each adapter. The profile can identify conflict resolution policies, synchronization filters, source and destination folders, sync direction, and the like.

Systems and methods for synchronizing with multiple data stores

The subject invention relates to systems and/or methods that perform an authoritative and/or a non-authoritative restore of items in a data store. Backups are provided that include data associated with items and metadata related to the items that can include a history of operations and previous synchronizations to enable replications to converge after restoration. The operations that can be performed on the items include, for example, create, delete, update, move, etc. The items in the backups can be restored along with the metadata, which can be utilized to enable synchronization partners to converge based on a desired type of restoration.

Authoritative and non-authoritative restore

Extending hierarchical synchronization (sync) scopes to non-hierarchical scenarios may involve a method for synchronizing differently organized data stores comprising mapping different physical organizations to similar logical organizations and utilizing an organization-based synchronization algorithm to synchronize the differently organized stores. Also, the uniqueness constraints of the organizations may be preserved as well as the parent-child ordering constraints of the organizations.

Extending hierarchical synchronization scopes to non-hierarchical scenarios

A uniform data structure contains a number of data fields. Some of the data fields are dedicated to contain information concerning the transfer of a data segment of a particular type (such as an XML segment) using one particular transfer mechanism (such as transferring as a string or DOM object, or transfer using an interface such as ISAXContentHandler, ITextSource, ITextSink, or IDOMSink interfaces). Other data fields are dedicated to contain information concerning the transfer of data segments of the same particular type using another transfer mechanism. When a module is to transfer a data segment, the module will cause the unified data structure to be altered as appropriate for the desired transfer mechanism.

Uniform transfer of data independent of the transfer mechanism

Methods for enabling mult-master synchronization of particular sets of data using filters. In a synchronization request, data including knowledge and filters may be supplied. A response may comprise data including changes that are identified by the filter and that have versions that are not known by the requestor.

Filtered replication of data stores

Systems and methods for replicating replicas in a sync community. Each replica in the sync community stores knowledge that represents changes the replica is aware of. Because each replica has its own knowledge, each replica does not need to know how many replicas are in the sync community or the topology of the sync community. By sending the knowledge with a request for changes, a replicating replica can enumerate the changes to replicate by comparing its knowledge with the received knowledge. After replication, the knowledge is updated. Knowledge may also include made-with-knowledge change IDs that permit each resolution to identify what a replica was aware of when a particular change was made. The made-with-knowledge values are used to detect conflicts during replication.

Growing community of inventors

Kirkland, WA, United States of America

Yunxin Wu