Computing device, method executed by computing device and non-transitory computer readable storage medium

Abstract

A computing device, a method executed by the computing device, and a non-transitory computer-readable storage medium are disclosed. The computing device includes: one or more processors; and one or more memories storing instructions that, when executed by the one or more processors, configure the computing device to perform operations, the operations including: accessing a partition; determining that the partition is locked by a transaction; completing the transaction, the transaction including metadata indicating a change to the transaction; and accessing the partition to read or write data.

Description

[0001] This application is a divisional application of patent application No. 202180087865.4 entitled "Decentralized Two-Phase Filing", filed on December 29, 2021, with international application number PCT / US2021 / 073171, and entered the Chinese national phase on June 27, 2023. Priority requirements

[0002] This application claims priority to U.S. Patent Application Serial No. 63 / 132,253, filed on December 30, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The examples in this disclosure generally relate to decentralized two-phase commit transactions. More specifically, but not limitingly, the examples in this disclosure relate to a decentralized module that performs a two-phase commit on data stored in a partition with a partition key. Background Technology

[0004] In traditional distributed data transaction environments, transactions are executed using a two-phase commit protocol across databases, client devices, servers, or cloud providers. Various programs send and receive transaction data through a centralized coordinator, which uses the two-phase commit protocol to manage transactions between computing devices. In the event of a transaction failure, the centralized coordinator delegates the two-phase commit protocol to each computing device by handling its own operations and routines. Summary of the Invention

[0005] According to one aspect of this disclosure, a computing device is disclosed. The computing device includes: one or more processors; and one or more memories storing instructions that, when executed by the one or more processors, configure the computing device to perform operations including: accessing a partition; determining that the partition is transaction-locked; completing the transaction, the transaction including metadata indicating changes to the transaction; and accessing the partition to read or write data.

[0006] According to another aspect of this disclosure, there is a method performed by a computing device. The method includes: accessing a partition; determining that the partition is transaction-locked; completing the transaction, the transaction including metadata indicating changes to the transaction; and accessing the partition to read or write data.

[0007] According to another aspect of this disclosure, there is a non-transitory computer-readable storage medium comprising instructions that, when executed by a first computing device, cause a computer to perform operations including: accessing a partition; determining that the partition is transaction-locked; completing the transaction, the transaction including metadata indicating changes to the transaction; and accessing the partition to read or write data. Attached Figure Description

[0008] In accompanying drawings that are not necessarily drawn to scale, the same reference numerals may describe similar parts in different views. For ease of identification of any particular element or action being discussed, one or more of the highest digits in the reference numerals indicate the drawing number in which the element was first introduced. Some non-limiting examples are shown in the figures of the accompanying drawings, in which:

[0009] Figure 1 It is a graphical representation of a networked environment in which the present disclosure can be deployed, based on some examples.

[0010] Figure 2 It is a graphical representation of a messaging system with both client-side and server-side functionalities, based on some examples.

[0011] Figure 3 It is a graphical representation based on examples such as data structures maintained in a database.

[0012] Figure 4 It is a graphical representation based on some example messages.

[0013] Figure 5 This is a flowchart illustrating access restriction processing based on some examples.

[0014] Figure 6 A system for decentralized two-phase commit is shown, based on some examples.

[0015] Figure 7 The method for two-phase commit in a decentralized manner is shown based on some examples.

[0016] Figure 8 The partitions are shown based on some examples.

[0017] Figure 9 An example of a method based on some examples is shown.

[0018] Figure 10 The method for completing a two-phase transaction that is interrupted is shown based on some examples.

[0019] Figure 11 The following is pseudocode for a two-phase commit for decentralization, based on some examples.

[0020] Figure 12 The method for performing a two-phase transaction is shown based on some examples.

[0021] Figure 13 It is a graphical representation of a machine in the form of a computer system, based on some examples, within which a set of instructions can be executed to cause the machine to perform any or more of the methods discussed herein.

[0022] Figure 14 A block diagram showing a software architecture in which an example can be implemented is shown.

[0023] Figure 15 It is a graphical representation of the processing environment based on some examples. Detailed Implementation

[0024] The following description includes systems, methods, techniques, instruction sequences, and computer program products that implement illustrative examples of the present disclosure. In the following description, numerous specific details are set forth for illustrative purposes to provide an understanding of various examples of the subject matter of the invention. However, it will be apparent to those skilled in the art that examples of the subject matter of the invention can be practiced without these specific details. Generally, well-known examples of instructions, protocols, structures, and techniques are not necessarily shown in detail.

[0025] In current distributed data transaction operations, the centralized coordinator is a software component that instructs computing devices to execute commit commands to complete all operations of the transaction or to execute rollback commands to undo all modifications made at the device level. The computing devices involved respond to the centralized coordinator with either a failure response or a completion response. If the response is positive, all operations are successfully completed, and the centralized coordinator sends an instruction to the computing devices to make the modifications permanent. If the response is a failure response, the centralized coordinator sends an instruction to all computing resources within the computing devices to roll back the changes.

[0026] Two-phase commit, or two-phase transaction, is a transaction in which two or more changes to a data field are performed either all together or none at all. When performing two-phase commit transactions between computing devices (such as client devices, servers, databases, or cloud providers), a centralized coordinator exhausts computing resources and incurs expensive computational costs. For example, a centralized coordinator utilizes unnecessary computing resources, increases network latency, and causes additional network failures. To reduce latency and improve reliability, maintaining a centralized coordinator requires additional computing resources.

[0027] The technical challenge is how to execute two-phase commit transactions without using a centralized server. This challenge is addressed as follows: The two-phase commit module is decentralized, and it uses metadata stored in association with the partition's partition key to lock and provide information for committing or rolling back the two-phase transaction. Furthermore, the metadata provides sufficient information so that if the device performing the two-phase commit operation fails, another device accessing the partition can complete the transaction.

[0028] In some examples, all reads and writes to a partition are guided (channeled) by one of the decentralized two-phase commit modules. This allows the two-phase commit module to ensure that data is not read from or written to a partition when there are pending two-phase commits, and also enables the device to detect when a two-phase transaction is interrupted by a device failure. The partitions involved in a two-phase transaction can be stored in different locations and can have different data organization.

[0029] Therefore, a centralized coordinator is no longer needed to coordinate transactions between databases, resulting in faster processing, more efficient use of storage, and improved reliability in cloud computing.

[0030] Networked computing environment

[0031] Figure 1 This is a block diagram illustrating an example messaging system 100 for exchanging data (e.g., messages and associated content) over a network. The messaging system 100 includes multiple instances of client devices 102, each hosting several applications including messaging clients 104 and other applications 106. Each messaging client 104 is communicatively coupled via a network 112 (e.g., the Internet) to other instances of messaging client 104 (e.g., hosted on corresponding other client devices 102), messaging server system 108, and third-party server 110. The messaging client 104 can also communicate with the locally hosted applications 106 using an application programming interface (API).

[0032] The messaging client 104 can communicate and exchange data with other messaging clients 104 and messaging server system 108 via network 112. The data exchanged between messaging clients 104 and between messaging clients 104 and messaging server system 108 includes functions (e.g., commands to activate functions) and payload data (e.g., text, audio, video, or other multimedia data).

[0033] Message transceiver server system 108 provides server-side functionality to specific message transceiver clients 104 via network 112. While some functions of message transceiver system 100 are described herein as being performed by message transceiver client 104 or message transceiver server system 108, the location of certain functions—whether within message transceiver client 104 or message transceiver server system 108—may be a design choice. For example, it may technically be preferred that certain technologies and functions are initially deployed within message transceiver server system 108, but that technology and functions are later migrated to message transceiver client 104 with sufficient processing power on client device 102.

[0034] The messaging server system 108 supports various services and operations provided to the messaging client 104. Such operations include sending data to and receiving data from the messaging client 104, and processing data generated by the messaging client 104. As an example, this data may include message content, client device information, geolocation information, media enhancements and overlays, message content persistence conditions, social network information, and live event information. Data exchange within the messaging system 100 is activated and controlled through functions available via the user interface (UI) of the messaging client 104.

[0035] Specifically, turning to message transceiver server system 108, application programming interface (API) server 116 is coupled to application server 114 and provides a programming interface to application server 114. Application server 114 is communicatively coupled to database server 120, which facilitates access to database 126, which stores data associated with messages processed by application server 114. Similarly, web server 128 is coupled to application server 114 and provides a web-based interface to application server 114. For this purpose, web server 128 handles incoming network requests via Hypertext Transfer Protocol (HTTP) and several other related protocols.

[0036] Application Programming Interface (API) server 116 receives and sends message data (e.g., commands and message payloads) between client device 102 and application server 114. Specifically, API server 116 provides a set of interfaces (e.g., routines and protocols) that can be invoked or queried by message transceiver client 104 to activate the functionality of application server 114. Application Programming Interface (API) server 116 exposes various functions supported by application server 114, including: account registration; login functionality; sending messages from one messaging client 104 to another messaging client 104 via application server 114; sending media files (e.g., images or videos) from messaging client 104 to messaging server 118, and for possible access by another messaging client 104; setting up a collection of media data (e.g., stories); retrieving a list of friends of a user on client device 102; retrieving such a collection; retrieving messages and content; adding and deleting entities (e.g., friends) in an entity graph (e.g., a social graph); locating friends within a social graph; and opening application events (e.g., related to messaging client 104).

[0037] Application server 114 hosts multiple server applications and subsystems, including, for example, messaging server 118, image processing server 122, and social networking server 124. Messaging server 118 implements multiple messaging technologies and functions, particularly relating to the aggregation and other processing of content (e.g., text and multimedia content) included in messages received from multiple instances of messaging client 104. As will be described in further detail, text and media content from multiple sources can be aggregated into collections of content (e.g., referred to as stories or galleries). These collections are then made available to messaging client 104. Given the hardware requirements for additional processor- and memory-intensive processing of data, such processing can also be performed on the server side by messaging server 118.

[0038] Application server 114 also includes image processing server 122, which is dedicated to performing various image processing operations on images or videos typically within the payload of messages sent from or received at message transceiver server 118.

[0039] Social network server 124 supports various social networking functions and services, and makes these functions and services available to messaging server 118. To this end, social network server 124 maintains and accesses entity graph 308 (such as...) within database 126. Figure 3(As shown). Examples of the functions and services supported by the social networking server 124 include identifying other users in the messaging system 100 who are related to a particular user or who are being "followed" by that particular user, and also identifying the interests and other entities of a particular user.

[0040] Returning to messaging client 104, the features and functionality of external resources (e.g., application 106 or applet) are available to the user via the interface of messaging client 104. In this context, "external" refers to the fact that application 106 or applet is outside of messaging client 104. External resources are typically provided by third parties, but may also be provided by the creator or provider of messaging client 104. Message client 104 receives user selections regarding options to launch or access the features of such external resources. External resources may be application 106 installed on client device 102 (e.g., a "native app"), or a smaller version (e.g., an "app") of an application hosted on client device 102 or located remotely on client device 102 (e.g., on a third-party server 110). A smaller version of an application includes a subset of the application's features and functionality (e.g., a full-scale, native version of the application) and is implemented using markup language documentation. In one example, a smaller version of an application (e.g., an "app") is a web-based markup language version of the application and is embedded in messaging client 104. In addition to using markup language documents (e.g., ...). In addition to ml files, small applications can include scripting languages ​​(e.g., ...). .js files or .json files) and stylesheets (e.g., ...). (SS file).

[0041] In response to a user selection of an option to launch or access an external resource, messaging client 104 determines whether the selected external resource is a web-based external resource or a locally installed application 106. In some cases, application 106, locally installed on client device 102, can be launched independently of messaging client 104 and separately from it, for example, by selecting the icon corresponding to application 106 on the home screen of client device 102. A smaller version of such an application can be launched or accessed via messaging client 104, and in some examples, no part of the smaller application can be accessed (or only a limited part can be accessed) outside of messaging client 104. A smaller application can be launched by messaging client 104, for example, by receiving and processing markup language documents associated with the smaller application from a third-party server 110.

[0042] In response to determining that the external resource is a locally installed application 106, the messaging client 104 instructs the client device 102 to launch the external resource by executing locally stored code corresponding to the external resource. In response to determining that the external resource is a web-based resource, the messaging client 104 communicates with a third-party server 110 (e.g.) to obtain a markup language document corresponding to the selected external resource. The messaging client 104 then processes the obtained markup language document to render the web-based external resource within the user interface of the messaging client 104.

[0043] The messaging client 104 can notify users of client device 102 or other users (e.g., "friends") associated with such users of one or more external resources of activities occurring in one or more external resources. For example, the messaging client 104 can provide participants in a conversation (e.g., a chat session) within the messaging client 104 with notifications related to the current or recent use of external resources by one or more members of a group of users. One or more users can be invited to join an active external resource or to activate an external resource that was recently used but is currently inactive (within the group of friends). External resources can provide participants in the conversation, each using the corresponding messaging client 104, with the ability to share items, states, conditions, or locations from the external resource to the chat session with one or more members of a group of users. Shared items can be interactive chat cards that chat members can use to interact, for example, to activate the corresponding external resource, view specific information within the external resource, or take chat members to a specific location or state within the external resource. Within a given external resource, response messages can be sent to users on the messaging client 104. External resources can selectively include different media items in the response based on the current context of the external resource.

[0044] The messaging client 104 can present a list of available external resources (e.g., application 106 or mini-app) to the user to launch or access a given external resource. This list can be presented in a context-sensitive menu. For example, the icons representing different applications 106 (or mini-apps) can change based on how the user launches the menu (e.g., from a conversational interface or a non-conversational interface).

[0045] System Architecture

[0046] Figure 2This is a block diagram illustrating further details of a messaging system 100 according to some examples. Specifically, the messaging system 100 is shown as including a messaging client 104 and an application server 114. The messaging system 100 includes multiple subsystems supported on the client side by the messaging client 104 and on the server side by the application server 114. These subsystems include, for example, a short-lived timer system 202, a collection management system 204, an enhancement system 208, a map system 210, a game system 212, an external resource system 214, and an interaction system 216.

[0047] The short-lived timer system 202 is responsible for enabling temporary or time-limited access to content by the message sending client 104 and the message sending server 118. The short-lived timer system 202 incorporates multiple timers that selectively enable access to (e.g., for rendering and displaying) messages and associated content via the message sending client 104 based on duration and display parameters associated with a message or set of messages (e.g., a story). Further details regarding the operation of the short-lived timer system 202 are provided below.

[0048] The collection management system 204 is responsible for managing collections and sets of media (e.g., collections of text, image, video, and audio data). Collections of content (e.g., messages, including images, videos, text, and audio) can be organized into "event galleries" or "event stories." Such collections can be made available for a specified time period, such as the duration of an event related to the content. For example, content related to a concert can be made available as a "story" during the duration of the concert. The collection management system 204 can also be responsible for publishing icons that provide notifications of the existence of specific collections to the user interface of the messaging client 104.

[0049] Furthermore, the collection management system 204 includes a curation interface 206 that enables the collection manager to manage and curate specific collections of content. For example, the curation interface 206 allows an event organizer to curate a collection of content related to a specific event (e.g., removing inappropriate content or redundant messages). Additionally, the collection management system 204 employs machine vision (or image recognition technology) and content rules to automatically curate content collections. In some examples, users may be compensated for including user-generated content in the collection. In such cases, the collection management system 204 operates to automatically pay such users for using their content.

[0050] Enhancement system 208 provides various functionalities that enable users to enhance (e.g., annotate or otherwise modify or edit) media content associated with a message. For example, enhancement system 208 provides functionalities related to generating and publishing media overlays for messages processed by messaging system 100. Enhancement system 208 can operable to provide media overlays or enhancements (e.g., image filters) to messaging client 104 based on the geolocation of client device 102. In another example, enhancement system 208 can operable to provide media overlays to messaging client 104 based on other information such as the social network information of the user of client device 102. Media overlays can include audio and visual content as well as visual effects. Examples of audio and visual content include pictures, text, logos, animations, and sound effects. Examples of visual effects include color overlays. Audio and visual content or visual effects can be applied to media content items (e.g., photos, digital objects) at client device 102. For example, media overlays can include text or images that can be overlaid on a photograph taken by client device 102. In another example, media overlays include location identifier overlays (e.g., Venice Beach), live event names, or business name overlays (e.g., Beach Cafe). In yet another example, enhancement system 208 uses the geolocation of client device 102 to identify media overlays that include the business name at the geolocation of client device 102. Media overlays may include additional tags associated with the business. Media overlays may be stored in database 126 and accessed through database server 120.

[0051] In some examples, enhancement system 208 provides a user-based publishing platform that allows users to select a geolocation on a map and upload content associated with that geolocation. Users can also specify the environment in which a particular media overlay should be provided to other users. Enhancement system 208 generates a media overlay that includes the uploaded content and associates the uploaded content with the selected geolocation.

[0052] In other examples, enhancement system 208 provides a merchant-based publishing platform that enables merchants to select specific media overlays associated with geolocations via a bidding process. For example, enhancement system 208 associates the media overlay of the highest bidder with a corresponding geolocation for a predefined amount of time.

[0053] Map system 210 provides various geolocation functions and supports the presentation of map-based media content and messages by messaging client 104. For example, map system 210 enables the display (e.g., stored in profile data 316) of user icons or avatars on a map to indicate the current or past location of a user's "friends" and media content (e.g., a collection of messages including photos and videos) generated by such friends within the context of the map. For example, a message posted by a user from a specific geolocation to messaging system 100 can be displayed to a specific user's "friends" on the map interface of messaging client 104 within the context of that specific location on the map. A user can also share his or her location and status information with other users of messaging system 100 (e.g., using appropriate status avatars) via messaging client 104, where the location and status information is similarly displayed to selected users within the context of the map interface of messaging client 104.

[0054] The game system 212 provides various game functions within the context of the messaging client 104. The messaging client 104 provides a game interface that displays a list of available games, which can be started by a user within the context of the messaging client 104 and played with other users of the messaging system 100. The messaging system 100 also enables specific users to invite other users to participate in specific games by sending invitations from the messaging client 104. The messaging client 104 also supports both voice and text messaging (e.g., chat) within the game context, provides leaderboards for the game, and also supports providing in-game rewards (e.g., game currency and items).

[0055] External resource system 214 provides an interface for messaging client 104 to communicate with remote servers (e.g., third-party server 110) to launch or access external resources (i.e., applications or applets). Each third-party server 110 hosts applications or smaller versions of applications (e.g., game applications, utility applications, payment applications, or ride-sharing applications) based on markup languages ​​(e.g., HTML5). Messaging client 104 can launch web-based resources (e.g., applications) by accessing HTML5 files from the third-party server 110 associated with the web-based resource. In some examples, the application hosted by third-party server 110 is programmed in JavaScript using a software development kit (SDK) provided by messaging server 118. The SDK includes an application programming interface (API) with functionality that can be invoked or activated by the web-based application. In some examples, messaging server 118 includes a JavaScript library that provides access to certain user data of messaging client 104 to a given external resource. HTML5 is used as an example technology for programming games, but applications and resources programmed based on other technologies can be used.

[0056] To integrate the SDK's functionality into the web-based resource, the SDK is downloaded by third-party server 110 from message server 118 or otherwise received by third-party server 110. Once downloaded or received, the SDK will be included as part of the application code of the web-based external resource. The code of the web-based resource can then call or activate certain functions of the SDK to integrate the features of message client 104 into the web-based resource.

[0057] The SDK stored on the messaging server 118 effectively bridges the gap between external resources (e.g., application 106 or applet) and the messaging client 104. This provides users with a seamless experience communicating with other users on the messaging client 104 while preserving the look and feel of the messaging client 104. To bridge communication between the external resource and the messaging client 104, in some examples, the SDK facilitates communication between a third-party server 110 and the messaging client 104. In some examples, a WebViewJavaScriptBridge running on the client device 102 establishes two unidirectional communication channels between the external resource and the messaging client 104. Messages are sent asynchronously between the external resource and the messaging client 104 via these communication channels. Each SDK function call is sent as a message and a callback. Each SDK function is implemented by constructing a unique callback identifier and sending a message with that callback identifier.

[0058] By using the SDK, not all information from the messaging client 104 is shared with the third-party server 110. The SDK limits which information is shared based on the needs of the external resource. In some examples, each third-party server 110 provides the messaging server 118 with an HTML5 file corresponding to the web-based external resource. The messaging server 118 can add a visual representation (such as a box design or other graphics) of the web-based external resource to the messaging client 104. Once the user selects a visual representation or instructs the messaging client 104 via its GUI to access the features of the web-based external resource, the messaging client 104 obtains the HTML5 file and instantiates the resources required to access the features of the web-based external resource.

[0059] The messaging client 104 presents a graphical user interface (GUI) for an external resource (e.g., a login page or title screen). During, before, or after presenting the login page or title screen, the messaging client 104 determines whether the initiated external resource has previously been authorized to access the messaging client 104's user data. In response to determining that the initiated external resource has previously been authorized to access the messaging client 104's user data, the messaging client 104 presents another GUI for the external resource, which includes the external resource's functionality and characteristics. In response to determining that the initiated external resource has not previously been authorized to access the messaging client 104's user data, after a threshold time period (e.g., 3 seconds) of displaying the external resource's login page or title screen, the messaging client 104 slides up a menu for authorizing the external resource to access user data (e.g., animating the menu to appear from the bottom of the screen to the middle or other part of the screen). This menu identifies the type of user data that the external resource will be authorized to use. In response to receiving a user's selection of the accept option, messaging client 104 adds the external resource to the list of authorized external resources and enables the external resource to access user data from messaging client 104. In some examples, the external resource is authorized by messaging client 104 to access user data according to the OAuth 2 framework.

[0060] The messaging client 104 controls the type of user data shared with external resources based on the type of authorized external resource. For example, it provides access to a first type of user data (e.g., a two-dimensional avatar of a user, with or without different avatar characteristics) to external resources including full-scale applications (e.g., application 106). As another example, it provides access to a second type of user data (e.g., payment information, a user's two-dimensional avatar, a user's three-dimensional avatar, and avatars with various avatar characteristics) to external resources including smaller versions of the application (e.g., a web-based version of the application). Avatar characteristics include different ways of customizing the appearance and feel of an avatar (e.g., different poses, facial features, clothing, etc.).

[0061] Two-phase system 216 provides functions and routines for performing two-phase commit transactions. Two-phase system 216 provides these functions and routines here and... Figures 6 to 12 The two-phase commit system 216 enables decentralized two-phase commit modules 614, 616, and 617 to execute two-phase transactions. Two-phase commit modules 614, 616, and 617 can operate in parallel access partitions. Two-phase commit modules 614, 616, and 617 are configured to handle all reads and writes to the partition and are configured to determine whether the partition is locked. Furthermore, two-phase commit modules 614, 616, and 617 are configured to detect when a two-phase transaction is interrupted and are configured to complete the two-phase commit transaction or roll back the two-phase commit transaction.

[0062] Data Architecture

[0063] Figure 3 This is a schematic diagram illustrating a data structure 300 that may be stored in a database 126 of a message transceiver server system 108, according to certain examples. Although the contents of the database 126 are shown as including multiple tables, it will be appreciated that the data may be stored in other types of data structures (e.g., stored as an object-oriented database).

[0064] Database 126 includes message data stored in message table 302. For any given message, this message data includes at least message sender data, message receiver (or recipient) data, and a payload. See below for reference. Figure 4 Further details are provided regarding information that can be included in the message and is contained within the message data stored in message table 302.

[0065] Entity table 306 stores entity data and (for example, links to entity diagram 308 and profile data 316). Entities for which records are maintained in entity table 306 can include individuals, company entities, organizations, objects, locations, events, etc. Regardless of the entity type, any entity whose data is stored in message transceiver server system 108 can be an identifiable entity. Each entity is assigned a unique identifier and an entity type identifier (not shown).

[0066] Entity graph 308 stores information about the relationships and associations between entities. As an example only, such relationships can be social relationships or professional relationships based on interests or activities (e.g., working in the same company or organization).

[0067] Profile data 316 stores various types of profile data about a specific entity. Based on privacy settings specified by the specific entity, profile data 316 can be selectively used and presented to other users of messaging system 100. In the case of an individual, profile data 316 includes, for example, a username, phone number, address, settings (e.g., notification and privacy settings), and an avatar representation (or a set of such avatar representations) selected by the user. A specific user can then selectively include one or more of these avatar representations within the content of messages transmitted via messaging system 100 and on a map interface displayed to other users by messaging client 104. The set of avatar representations may include “status avatars,” which present a graphical representation of a status or activity that the user can choose to transmit at a specific time.

[0068] In the case that the entity is a group, in addition to the group name, members and various settings for the relevant group (e.g., notifications), the profile data 316 for the group may similarly include one or more avatars associated with the group.

[0069] Database 126 also stores enhancement data, such as overlays or filters, in enhancement table 310. The enhancement data is associated with and applied to videos (video data is stored in video table 304) and images (image data is stored in image table 312).

[0070] In one example, a filter is an overlay displayed on an image or video during presentation to the receiving user. Filters can be of various types, including user-selected filters from a set of filters presented to the sending user by the messaging client 104 while the sending user is composing a message. Other types of filters include geolocation filters (also known as geographic filters), which can be presented to the sending user based on geographic location. For example, a geolocation filter specific to a nearby or particular location can be presented by the messaging client 104 within the user interface based on geolocation information determined by the Global Positioning System (GPS) unit of the client device 102.

[0071] Another type of filter is a data filter, which can be selectively presented to the sending user by the messaging client 104 based on other inputs or information collected by the client device 102 during the message creation process. Examples of data filters include the current temperature at a specific location, the current speed of the sending user, the battery life of the client device 102, or the current time.

[0072] Other augmented data that can be stored in image table 312 includes augmented reality content items (e.g., corresponding to an applied lens or augmented reality experience). Augmented reality content items can be real-time special effects and sounds that can be added to images or videos.

[0073] As described above, augmented data includes augmented reality content items, overlays, image transformations, AR images, and similar terms referring to modifications that can be applied to image data (e.g., video or images). This includes real-time modifications, which modify the image as it is captured by the device sensors (e.g., one or more cameras) of client device 102 and then, if modified, displayed on the screen of client device 102. This also includes modifications to stored content (e.g., video clips in a gallery that can be modified). For example, in client device 102 that accesses multiple augmented reality content items, a user can use a single video clip with multiple augmented reality content items to see how different augmented reality content items will modify the stored clip. For example, by selecting different augmented reality content items for the same content, multiple augmented reality content items with different pseudo-random motion models can be applied to that same content. Similarly, real-time video capture can be used with the illustrated modifications to show how the video image currently being captured by the sensors of client device 102 will modify the captured data. Such data can be displayed on the screen without being stored in memory, or the content captured by the device's sensors can be recorded and stored in memory with or without modification (or both). In some systems, preview features can simultaneously show how different augmented reality content items will look in different windows on the display. For example, this can make it possible to view multiple windows with different pseudo-random animations on the display at the same time.

[0074] Therefore, using data from augmented reality content items and various systems, or other such transformation systems that use this data to modify content, can involve: the detection of objects (e.g., faces, hands, bodies, cats, dogs, surfaces, objects, etc.) in video frames; tracking such objects as they leave, enter, and move around within the field of view; and modifying or transforming such objects while tracking them. In various examples, different methods can be used to implement such transformations. Some examples may involve generating 3D mesh models of one or more objects, and using transformations and animated textures of the models within the video to implement the transformations. In other examples, tracking points on objects can be used to place images or textures (which can be two-dimensional or three-dimensional) at the tracked locations. In still other examples, neural network analysis of video frames can be used to place images, models, or textures within content (e.g., images or video frames). Thus, augmented reality content items involve both images, models, and textures used to create transformations within the content, and the additional modeling and analysis information required to implement such transformations using object detection, tracking, and placement.

[0075] Real-time video processing can be performed using any type of video data (e.g., video streams, video files, etc.) stored in the memory of any type of computerized system. For example, a user can load a video file and store it in the device's memory, or the device's sensors can be used to generate a video stream. Additionally, computer-animated models can be used to process any object, such as a human face and parts of the human body, animals, or inanimate objects (e.g., chairs, cars, or other objects).

[0076] In some examples, when a specific modification is selected along with the content to be transformed, the computing device identifies the element to be transformed, and then, if the element to be transformed exists in a frame of the video, detects and tracks the element to be transformed. The elements of the object are modified according to the modification request, thus transforming the frames of the video stream. For different kinds of transformations, the transformation of the video stream frames can be performed using different methods. For example, for frame transformations that primarily involve changing the form of elements of an object, feature points of each element of the object are calculated (e.g., using an Active Shape Model (ASM) or other known methods). Then, a feature point-based mesh is generated for each of at least one element of the object. This mesh is used in subsequent stages of tracking the elements of the object in the video stream. During tracking, the aforementioned mesh for each element is aligned with the position of each element. Then, additional points are generated on the mesh. A first set of first points is generated for each element based on the modification request, and a second set of points is generated for each element based on this set of first points and the modification request. The frames of the video stream can then be transformed by modifying the elements of the object based on the set of first points, the set of second points, and the mesh. In this method, the background of the object being modified can also be changed or distorted by tracking and modifying the background.

[0077] In some examples, transformations that alter certain regions of an object using its elements can be performed by calculating characteristic points for each element of the object and generating a mesh based on those calculated characteristic points. Points are generated on the mesh, and then various regions are generated based on these points. The elements of the object are then tracked by aligning the region of each element with the position of at least one of the elements, and the properties of the regions can be modified based on modification requests, thus transforming frames of the video stream. Depending on the specific modification request, the properties of the mentioned region can be transformed in different ways. Such modifications can involve: changing the color of the region; removing at least a portion of the region from the frames of the video stream; including one or more new objects in the region based on the modification request; and modifying or distorting the elements of the region or object. In various examples, any combination of such modifications or other similar modifications can be used. For certain models to be animated, some characteristic points can be selected as control points to determine the entire state space for options used in model animation.

[0078] In some examples of computer animation models that use face detection to transform image data, a specific face detection algorithm (e.g., Viola-Jones) is used to detect faces in the image. The Active Shape Model (ASM) algorithm is then applied to the facial regions of the image to detect facial feature reference points.

[0079] Other methods and algorithms suitable for face detection can be used. For example, in some examples, landmarks are used to locate features; landmarks represent distinguishable points present in most of the images considered. For example, for facial landmarks, the location of the left pupil could be used. If the initial landmark is not identifiable (e.g., if the person has an eye patch), secondary landmarks can be used. Such a landmark identification process can be used for any such object. In some examples, a set of landmarks forms a shape. The shape can be represented as a vector using the coordinates of the points in the shape. One shape is aligned with another shape using a similarity transformation (allowing translation, scaling, and rotation) that minimizes the average Euclidean distance between the points of the shape. The mean shape is the mean of the aligned training shapes.

[0080] In some examples, the search for landmarks begins with a mean shape aligned with the position and size of the face determined by a global face detector. This search then repeats the following steps: proposing provisional shapes by adjusting the localization of shape points through template matching of the image texture around each point, and then conforming the provisional shapes to a global shape model until convergence occurs. In some systems, individual template matching is unreliable, and the shape model pools the results of weak template matching to form a stronger overall classifier. The entire search is repeated at each level of the image pyramid, from coarse to fine resolution.

[0081] The transformation system can capture image or video streams on a client device (e.g., client device 102) and perform complex image manipulations locally on client device 102 while maintaining an appropriate user experience, computation time, and power consumption. Complex image manipulations can include size and shape changes, mood shifts (e.g., changing a face from frowning to smiling), state shifts (e.g., aging an object, reducing its apparent age, or changing its gender), style shifts, application of graphical elements, and any other suitable image or video manipulations implemented by a convolutional neural network that has been configured to execute efficiently on client device 102.

[0082] In some examples, a computer animation model for transforming image data can be used by a system in which a user can capture an image or video stream (e.g., a selfie) using a client device 102 that has a neural network operating as part of a messaging client 104 operating on client device 102. A transformation system operating within messaging client 104 determines the presence of a face within the image or video stream and provides a modification icon associated with the computer animation model to transform the data image, or the computer animation model may exist in association with an interface described herein. The modification icon includes changes that can be the basis for modifying the user's face within the image or video stream as part of a modification operation. Once a modification icon is selected, the transformation system initiates a process to transform the user's image to reflect the selected modification icon (e.g., generating a smiley face on the user). Once the image or video stream is captured and the specified modification is selected, the modified image or video stream can be presented in a graphical user interface displayed on client device 102. The transformation system may implement a complex convolutional neural network on a portion of the image or video stream to generate and apply the selected modification. That is, users can capture image or video streams, and once an edit icon is selected, the changes are presented to the user in real time or near real time. Furthermore, while a video stream is being captured, the changes can be persistent, and the selected edit icon remains toggled. Machine-trained neural networks can be used to achieve such modifications.

[0083] The graphical user interface (GUI) presenting the modifications performed by the transformation system can provide users with additional interactive options. Such options can be based on the interface used to initiate the selection and content capture of a specific computer animation model (e.g., initiated from a content creator GUI). In various examples, the modifications can be persistent after an initial selection of the modification icon. Users can turn the modification on or off by tapping or otherwise selecting the face being modified by the transformation system and save it for later viewing or browsing to other areas of the imaging application. In cases where multiple faces are modified by the transformation system, users can globally turn the modification on or off by tapping or selecting a single face being modified and displayed within the GUI. In some examples, individual faces within a set of multiple faces can be modified separately, or such modifications can be toggled individually by tapping or selecting individual faces or a series of individual faces displayed within the GUI.

[0084] Story table 314 stores data about collections of messages and associated image, video, or audio data, compiled into collections (e.g., stories or galleries). The creation of a specific collection can be initiated by a specific user (e.g., each user whose records are maintained in entity table 306). A user can create a "personal story" in the form of a collection of content that has been created and sent / broadcast by that user. For this purpose, the user interface of messaging client 104 may include user-selectable icons that allow the sending user to add specific content to his or her personal story.

[0085] The collection can also constitute a "live story," which is a collection of content from multiple users created manually, automatically, or using a combination of manual and automatic techniques. For example, a "live story" can constitute a curated stream of user-submitted content from different locations and events. Users whose client devices have location services enabled and who are at a co-located event at a specific time can be presented with the option to contribute content to a specific live story, for example, via the user interface of messaging client 104. The messaging client 104 can identify a live story to a user based on their location. The end result is a "live story" told from a collective perspective.

[0086] Another type of content collection is called a "location story," which allows users whose client devices 102 are located in a specific geographic location (e.g., on a college or university campus) to contribute to a specific collection. In some examples, contributing to a location story may require secondary authentication to verify that the end user belongs to a specific organization or other entity (e.g., a student on a university campus).

[0087] As mentioned above, video table 304 stores video data, which in one example is associated with a message whose record is maintained within message table 302. Similarly, image table 312 stores image data associated with a message whose message data is stored in entity table 306. Entity table 306 can associate various enhancements from enhancement table 310 with various images and videos stored in image table 312 and video table 304.

[0088] Data communication architecture

[0089] Figure 4This is a schematic diagram illustrating the structure of a message 400 according to some examples, generated by a messaging client 104 for transmission to another messaging client 104 or a messaging server 118. The content of a particular message 400 is used to populate a message table 302 stored in a database 126 accessible by the messaging server 118. Similarly, the content of message 400 is stored in memory as "in-transit" or "in-flight" data for the client device 102 or application server 114. Message 400 is shown as including the following example components:

[0090] Message Identifier 402: A unique identifier that identifies message 400.

[0091] Message text payload 404: The text to be generated by the user via the user interface of the client device 102 and included in message 400.

[0092] Message image payload 406: Image data captured by the camera component of the client device 102 or retrieved from the memory component of the client device 102 and included in the message 400. The image data for the sent or received message 400 can be stored in the image table 312.

[0093] Message video payload 408: Video data captured by the camera device component or retrieved from the memory component of the client device 102 and included in message 400. The video data for the sent or received message 400 can be stored in video table 304.

[0094] Message audio payload 410: Audio data captured by the microphone or retrieved from the memory component of the client device 102 and included in message 400.

[0095] Message enhancement data 412: Enhancement data (e.g., filters, labels, or other annotations or enhancements) representing enhancements to be applied to the message image payload 406, message video payload 408, or message audio payload 410 of message 400. Enhancement data for the sent or received message 400 can be stored in enhancement table 310.

[0096] Message duration parameter 414: A parameter value, in seconds, indicating the amount of time that the content of the message (e.g., message image payload 406, message video payload 408, message audio payload 410) will be presented to the user or made accessible to the user via the message sending and receiving client 104.

[0097] Message geolocation parameter 416: Geolocation data (e.g., latitude and longitude coordinates) associated with the message's content payload. Multiple message geolocation parameter 416 values ​​may be included in the payload, each of which is associated with a content item included in the content (e.g., a specific image within the message image payload 406 or a specific video within the message video payload 408).

[0098] Message Story Identifier 418: An identifier value that identifies one or more sets of content (e.g., "Stories" identified in Story Table 314) associated with a specific content item in the message image payload 406 of message 400. For example, the identifier value can be used to associate multiple images within the message image payload 406 with multiple sets of content, respectively.

[0099] Message Tag 420: Each message 400 can be labeled with multiple tags, each of which indicates the subject of the content included in the message payload. For example, in the case where a specific image depicts an animal (e.g., a lion) is included in the message image payload 406, a tag value can be included within the message tag 420 indicating the relevant animal. Tag values ​​can be manually generated based on user input, or can be automatically generated using, for example, image recognition.

[0100] Message sender identifier 422: An identifier (e.g., a message sending system identifier, email address, or device identifier) ​​indicating the user of the client device 102 on which message 400 is generated and from which message 400 is sent.

[0101] Message receiver identifier 424: An identifier (e.g., message sending and receiving system identifier, email address, or device identifier) ​​indicating the user of the client device 102 to which message 400 is addressed.

[0102] The content (e.g., values) of each component of message 400 can be pointers to locations in tables where content data values ​​are stored. For example, image values ​​in message image payload 406 can be pointers (or addresses) to locations within image table 312. Similarly, values ​​in message video payload 408 can point to data stored in video table 304, values ​​stored in message enhancement 412 can point to data stored in enhancement table 310, values ​​stored in message story identifier 418 can point to data stored in story table 314, and values ​​stored in message sender identifier 422 and message receiver identifier 424 can point to user records stored in entity table 306.

[0103] Time-based access restriction architecture

[0104] Figure 5 This is a schematic diagram illustrating an access restriction process 500, according to which access to content (e.g., a short message 502 and its associated multimedia data payload) or a collection of content (e.g., a short message group 504) can be time-restricted (e.g., made short-lived).

[0105] A brief message 502 is shown as associated with a message duration parameter 506, the value of which determines the amount of time the message sending and receiving client 104 will display the brief message 502 to the receiving user. In one example, depending on the amount of time specified by the sending user using the message duration parameter 506, the receiving user can view the brief message 502 for up to 10 seconds.

[0106] Message duration parameter 506 and message receiver identifier 424 are shown as inputs to message timer 510, which is responsible for determining the amount of time for which brief message 502 is shown to a specific receiving user identified by message receiver identifier 424. Specifically, brief message 502 is shown to the relevant receiving user only within the time period determined by the value of message duration parameter 506. Message timer 510 is shown as providing an output to a more generalized brief timer system 202, which is responsible for the overall timing of displaying content (e.g., brief message 502) to the receiving user.

[0107] Figure 5The transient message 502 shown is included within a transient message group 504 (e.g., a collection of messages in a personal story or event story). The transient message group 504 has an associated group duration parameter 508, the value of which determines the duration for which the transient message group 504 is presented and accessible to a user of the messaging system 100. For example, the group duration parameter 508 could be the duration of a concert, where the transient message group 504 is a collection of content related to that concert. Alternatively, when setting up and creating the transient message group 504, the user (owner user or curator user) can specify the value of the group duration parameter 508.

[0108] Additionally, each short message 502 within a short message group 504 has an associated group participation parameter 512, the value of which determines the duration for which the short message 502 is accessible within the context of the short message group 504. Therefore, a particular short message group 504 can "expire" and become inaccessible within its context before the short message group 504 itself expires according to the group duration parameter 508. The group duration parameter 508, the group participation parameter 512, and the message receiver identifier 424 each provide input to a group timer 514, which is operable to first determine whether a particular short message 502 of the short message group 504 will be displayed to a specific receiving user, and if so, determine for how long. Note that the short message group 504 also knows the identity of the specific receiving user due to the message receiver identifier 424.

[0109] Therefore, the group timer 514 operatively controls the associated ephemeral message group 504 and the total lifetime of the individual ephemeral messages 502 included within the ephemeral message group 504. In one example, each ephemeral message 502 within the ephemeral message group 504 remains viewable and accessible for a period of time specified by the group duration parameter 508. In another example, within the context of the ephemeral message group 504, a particular ephemeral message 502 may expire based on the group participation parameter 512. Note that even within the context of the ephemeral message group 504, the message duration parameter 506 can still determine the duration for which a particular ephemeral message 502 is displayed to the receiving user. Therefore, the message duration parameter 506 determines the duration for which a particular ephemeral message 502 is displayed to the receiving user, regardless of whether the receiving user views the ephemeral message 502 within or outside the context of the ephemeral message group 504.

[0110] The short-lived timer system 202 can also operatively remove a specific short-lived message 502 from the short-lived message group 504 based on determining that the associated group participation parameter 512 has expired. For example, when the sending user has established a group participation parameter 512 of 24 hours from the date of publication, the short-lived timer system 202 will remove the associated short-lived message 502 from the short-lived message group 504 after the specified 24 hours. The short-lived timer system 202 also operates to remove the short-lived message group 504 when the group participation parameter 512 of each short-lived message 502 within the short-lived message group 504 has expired, or when the short-lived message group 504 itself has expired according to the group duration parameter 508.

[0111] In certain use cases, the creator of a specific ephemeral message group 504 can specify an indefinite group duration parameter 508. In this case, the expiration of the group participation parameter 512 of the last remaining ephemeral message 502 within the ephemeral message group 504 will determine when the ephemeral message group 504 itself expires. In this case, adding a new ephemeral message 502 with a new group participation parameter 512 to the ephemeral message group 504 effectively extends the lifetime of the ephemeral message group 504 to a value equal to the group participation parameter 512.

[0112] In response to the short-lived timer system 202 determining that a short-lived message group 504 has expired (e.g., is no longer accessible), the short-lived timer system 202 communicates with the messaging system 100 (and, in particular, the messaging client 104) to cause the markers (e.g., icons) associated with the relevant short-lived message group 504 to no longer be displayed in the user interface of the messaging client 104. Similarly, when the short-lived timer system 202 determines that the message duration parameter 506 for a particular short-lived message 502 has expired, the short-lived timer system 202 causes the messaging client 104 to no longer display the markers (e.g., icons or text labels) associated with the short-lived message 502.

[0113] Decentralized two-phase commit

[0114] Figure 6A system 600 for decentralized two-phase commit is illustrated according to some examples. Client devices 602, 604 may be the same as or similar to client device 102. Applications 608, 610, 612 may reside on client devices 602, 604, message transceiver server system 108, or another computing device, or run on client devices 602, 604, message transceiver server system 108, or another computing device. Applications 608, 610, 612 each include a portion that performs a two-phase commit based on functionality provided by two-phase commit module 614. In some examples, applications 608, 610, 612 are compiled such that code for two-phase commit is included within the code. In some examples, applications 608, 610, 612 call runtime libraries to activate the functionality required to perform a two-phase commit. Two-phase commit modules 614, 616, 617 are depicted as optional because there may not be actual modules, but rather code for two-phase commit or runtime calls to two-phase commit functionality may be included. Two-phase commit modules 614, 616, and 617 can be decentralized, so that each of the applications 608, 610, and 612 does not activate or call a centralized module to perform a two-phase commit on the data.

[0115] Instead of a central coordinator, all read and write operations are funnel-shaped through two-phase commit modules 614, 616, and 617, which are responsible for completing any pending two-phase commit transactions, pre-verification checks, executing modified commit protocols, etc. In some examples, applications on application server 114 use two-phase commit modules 614, 616, and 617. In some examples, message client 104, application 106, and other applications use two-phase commit modules 614, 616, and 617. In some examples, all applications accessing data from message server system 108 or third-party server 110 (e.g., Figure 2 The system uses two-phase commit modules 614, 616, and 617 to ensure data consistency. In some examples, database server 120 ensures that applications accessing database 126 or other data use the two-phase commit method disclosed herein.

[0116] Two-phase commit involves changing the values ​​of at least two fields within data repository 606 or database 126. For example, changing data 636 and 640 for at least two fields or objects associated with residual keys 634 and 638. Leader partition 620 and follower partition 622 can be stored in different locations. Partition keys 626 and 628 are partition keys that can include attributes or paths to follower partition 622 and leader partition 620, respectively. For example, partition keys 626 and 628 can be JavaScript object symbolic (JSON) properties that include data paths. Partition keys 626 and 628 identify one or more data objects. In some examples, partition keys 626 and 628 include one or more columns that determine the partition where each row is stored. Partition keys 626 and 628 define a subset of data objects and can be used to access the data objects. Residual keys 634 and 638 are used to access data 636 and 640, respectively. Metadata 630 and 632 are used by applications 608, 610, 612 and / or two-phase commit modules 614, 616, 617 to perform a two-phase commit. As shown in the figure, metadata 630 is associated with partition key 626 and metadata 632 is associated with partition key 628, but metadata 630, 632 and partition keys 626, 628 can be stored differently.

[0117] The terms leader and follower are selected by the two-phase commit method and indicate the roles played by metadata 630 associated with partition key 626 and metadata 632 associated with partition key 628 in executing the two-phase commit method. Application 612 is configured to perform a two-phase commit without accessing a central two-phase commit coordinator. Metadata 630, 632 ensure that the two-phase commit is executed correctly even if client devices 602, 604 or message server system 108 stops operating correctly during the execution of the two-phase commit. Each of applications 608, 610, 612 can execute a two-phase commit independently. The two-phase commit method ensures that data 636 from follower partition 622 and data 640 from leader partition 620 are either changed together or not changed.

[0118] Figures 7 to 9 They are publicly displayed in combination. Figure 7 The method 700 for decentralized two-phase commit is shown based on some examples. Figure 8 Partition 800 is shown based on some examples. Figure 9 Example 900 is shown based on method 700 of some examples.

[0119] Method 700 is executed by two-phase commit modules 614, 616, and 617. Method 700 begins with operation 702, where the leader partition key is selected. For example, refer to... Figure 8 Partition 800 includes three partitions with partition keys "UserA", "UserB", and "UserC". The two-phase transaction is used to perform the acceptance of a friend request between UserA and UserC. Partition key 802 is used in NoSQL databases, where all data related to a single person or entity is juxtaposed and stored together. For example, several rows can be stored under the same partition key 802. Method 700 is illustrated using partition key 802, but those skilled in the art will recognize that other types of keys used for databases or data organization can be used, where partition key 802 or another type of key is accessed to determine if the data is locked before accessing the data. See reference... Figure 9 The diagram shows operation 902, partition key 802 UserA 904, and partition key 802 UserC 906 along the top. Example 900 shows the changes in the values ​​of the data used in method 700 for each operation 902.

[0120] Metadata 911 and 918 are stored in hidden rows associated with UserA 904 and UserC 906, respectively. For example, for a user relationship table stored in database 126 or data repository 606, there is separate transaction metadata for each user in the messaging system, stored alongside the relationship metadata row. The transaction metadata informs the client whether a transaction involving a specific partition key 802 is in progress. Figure 8 and Figure 9 In the example, the transaction is a user relationship. Metadata 911, 918 contains sufficient information to ensure that if the two-phase transaction is interrupted (e.g., becomes ineffective via one device), the two-phase transaction is completed by another device. Furthermore, normal access to a partition with partition key 802 and remaining key 804 is modified such that before accessing data within the partition, metadata 911, 918 is checked to determine whether the partition is locked or in the process of a two-phase transaction. Those skilled in the art will recognize that other locking mechanisms can be used for data with stored metadata.

[0121] Continuing with Example 900, at operation 702, UserA 904 is selected as role 908 with the leader partition key, and UserC 906 is selected as role 916 with the follower partition key. Roles 908 and 916 can be designated by the values ​​used in metadata 911 and 918, and / or stored locally within the modules performing the two-phase commit (e.g., two-phase commit modules 614, 616, and 617). Because two-phase commit can include more than two transactions, there can be more than one follower partition.

[0122] Method 700 continues at operation 704, where the transaction is verified to ensure all partitions are unlocked. For example, a two-phase transaction includes partition key 802 UserA and partition key 802 UserC. Two-phase commit modules 614, 616, and 617 perform checks to ensure partition keys 802 UserA and 802 UserC are not locked, which can be determined by metadata 911 and 918, respectively. If the transaction metadata is equal to None or Nil, then partitions UserA and UserC are determined not to be locked. Furthermore, version 909 (version = 1) of partition key 802 UserA 904 is stored, and version 906 (version = 10) of partition key 802 UserC is stored. These values ​​are shown in the row of operation 704 of operation 902. Each partition key 802 and row has a version number that ensures atomic, consistent, isolated, and durable (ACID) transactions are performed using partition 800. The snapshot reads of partition 800 by the two-phase commit modules 614, 616, and 617 allow the concurrent modules to make progress on the two-phase transaction.

[0123] Two-phase commit modules 614, 616, and 617 read partition 800 by applying any pending transactions before reading data. These modules ensure that any pending transactions are properly flushed before the read is made available when rows in partition 800 are read. This ensures that there are no pending, unapplied transactions, and if any exist, drives those transactions to completion. Two-phase commit modules 614, 616, and 617 ensure that all transactional read operations conform to snapshot read semantics by tracking row versions 909 and 917.

[0124] If operation 704 fails, for example, if partition UserA or partition UserC is locked, method 700 continues to operation 718, where the two-phase commit is aborted. Furthermore, as combined with... Figure 11 The specific routines described, such as pseudocode 1122, can verify that conditions are valid for executing a transaction or a two-phase commit. For example, for Figure 8 and Figure 9 For example, before executing the two-phase transaction “accept friend request” shown in pseudocode 1122, pseudocode 1122 can check that the partition key 802 UserA with the remaining key 804 UserC (UserA / UserC) is set to the value 806: “Type: Friend Request Sent”, and check that UserC / UserA is set to the value 806: “Type: Friend Request Received”.

[0125] Method 700 continues at operation 706, where the leader partition metadata is initialized to include the state "preparing" and transaction mutations. For example, the TransactionMetadata of partition UserA of partition 800 is set to "state: preparing" and "mutations: UserA.type = Friend; UserC.type = Friend", where version 909 maintains "version = 1". Versions 909 and 917, "1" and "10" respectively, can be additionally stored in change 912 and / or in the memory of two-phase commit modules 614, 616, and 617. These changes are shown at the line of operation 706 in operation 902. If operation 706 fails, for example, if partition key 802, which has been assigned the leader role 908, is locked by another module before operation 706, then method 700 continues to operation 718, where the two-phase commit is aborted.

[0126] Method 700 continues at operation 708, where the metadata of all follower partitions is set to be locked by the leader partition. For example, continue. Figure 8 and Figure 9In the example, the metadata 918 of UserC 906 is set to "Locked: UserA" at transaction 919. Metadata 918 can also be set to "Transaction: Locked: UserA". Metadata 918 contains enough information for another module to determine that UserC 906 is locked by UserA 904. The version number is retained as 10. These changes are shown in the line of operation 708 in operation 902 in example 900. If operation 708 fails, for example, if the metadata 918 of UserC 906 is not nil or the version number has changed from 10 (from the stored version of operation 704), then method 700 continues to operation 718, where the two-phase commit is aborted. Aborted operation 718 includes resetting transaction 919 to nil and resetting the state 910 of UserA 904 to nil. Operation 708 can include more than one follower, allowing one follower, such as UserC 906, to modify metadata 918, while another follower can be locked by another module. Furthermore, when multiple followers exist, operation 708 can be executed in parallel.

[0127] Method 700 continues at operation 710, where the leader partition metadata state is changed to committed and the transaction is applied to the leader partition. For example, continue. Figure 8 and Figure 9 In the example, UserA 904's state 910 is set to "Committed". Metadata 911 can be set to "state: Committed". UserA 904's version 909 is updated from 1 to 2 to indicate that the actual value of the data has changed. These changes are shown in Example 900 at the line of Operation 710 of Operation 902.

[0128] Furthermore, if the device executing method 700 stops operating normally or crashes after operation 710, the second device 720 can continue method 700 to completion without any additional information using metadata 911 associated with User A 904 and metadata 918 associated with User C 906. Method 1000 illustrates a method for completing a transaction in the event that the device executing method 700 stops operating.

[0129] Method 700 continues at operation 712, where transactions are performed on all follower partitions and the metadata status is set to committed but not applied. For example, continue. Figure 8 and Figure 9In the example, UserC / UserA: type 920 is set to "friend". Version 917 of UserC 906 is incremented to indicate that the actual data of UserC 906 has changed. Transaction 919 is set to nil. These changes are shown in the line of operation 712 of operation 902 in example 900. Furthermore, if the device executing method 700 crashes or stops operating normally after operation 712, another device can continue method 700 to completion without any additional information using metadata 911 associated with UserA 904 and metadata 918 associated with UserC 906. Method 1000 illustrates method 1000 for completing a transaction if the device executing method 700 stops operating.

[0130] Method 700 continues at operation 714, where the leader partition metadata state is changed to nil and the change is removed from the metadata. For example, continue. Figure 8 and Figure 9 In the example, state 910 is changed to nil, and change 912 is also changed to nil. These changes are shown in line 714 of operation 902 in example 900. The transaction has already been executed within partition 800.

[0131] Figure 10 A method 1000 for a two-phase transaction with interrupted completion is shown, based on some examples. Reads and writes to partition 800 are performed funnel-like through two-phase commit modules 614, 616, and 617, which are not necessarily centralized. Method 1000 begins with operation 1002, where the partition is accessed. For example, see reference... Figure 9 You can access UserA 904 or UserC 906. As an example, a module might want to access UserC / UserA: type and first check metadata 918 to determine if the data can be accessed or if there is a lock.

[0132] Method 1000 continues at operation 1004, where a lock is searched in the partition. For example, lines 706, 708, 710, and 712 indicate a lock for UserA 904, and lines 708 and 710 indicate a lock for UserC 906.

[0133] Method 1000 continues at operation 1006, where the transaction that locks the partition is completed. For example, if UserA 904 is accessed and state 910 is committed, and the changes are "UserA.type = friend" and "UserC.type = Friend", then it is determined that method 700 was aborted at operation 710. Method 1000 completes method 700 by first ensuring operation 710 is completed by checking whether a two-phase transaction has been applied to UserA / UserC: type 914. If no two-phase transaction has been applied, UserA / UserC: type 914 is set to friend. Then, operations 712 and 714 are executed by method 1000. The information provided in metadata 911 and 918 provides sufficient information to complete the two-phase transaction if it is aborted in method 700. Furthermore, method 1000 can complete the aborted operation 718. For example, refer to... Figure 9 If state 910 is ready and the metadata indicates “UserA.type = friend” and “UserC.type = Friend”, then method 1000 can set state 910 to nil and change 912 to nil to reset partition 800 before method 700 reaches the point of committing the two-phase transaction after method 700 fails, which is operation 710 in this example.

[0134] Method 1000 continues at operation 1008, where the partition is revisited. For example, the module revisits partition UserC 906 to determine the value of UserC / UserA: type 920, which can now be 'friend' after method 1000 has already completed method 700. Method 1000 may include one or more additional operations. The operations of method 1000 may be performed in different orders. One or more operations of method 1000 may be optional. Method 1000 may be performed by client device 102, message transceiver server system 108, and / or another device. Part of the functionality may be performed on a server computer or host.

[0135] Figure 11The following is pseudocode 1122 for a decentralized two-phase commit based on some examples. Pseudocode 1122 is a function for accepting friend requests, shown as "acceptfriendrequest" at line 1101. At line 1102, the transaction object "T" is set to "onedata.begintransaction()". "Onedata" is the name of two-phase commit modules 614, 616, and 617. Line 1120 indicates the line number assigned to pseudocode 1122. The method "begintransaction" ("start transaction") returns a two-phase transaction object. "begin transaction" accesses two-phase commit modules 614, 616, and 617.

[0136] Lines 1103 and 1104 access partitions 800 UserA and UserC, and check whether either partition 800 UserA or UserC is locked, and refer to... Figure 9 Note that partitions UserA 904 are version 909 and UserC 906 are version 917. The function ends if either UserA 904 or UserC 906 is locked. Similarly, lines 1105 and 1106 access partitions 800 UserC and UserA, and check if either partition 800 UserC or UserA is locked. Lines 1107, 1108, 1109, 1110, and 1111 check to ensure that UserA 904 and UserC 906 have sent and received friend requests, respectively. The function ends if friend requests have not been sent and received.

[0137] Lines 1112, 1113, 1114, and 1115 set UserA 904 and UserC 906 as friends within the memory object of `acceptfriendrequest`. Lines 1116 and 1117 execute method 700 to perform a two-phase transaction. The operations in lines 1112 through 1115 are executed in memory and then passed to method 700 to actually perform a two-phase commit on partition 800. This type of transaction is called a pessimistic transaction because the transaction is not locked before execution but is executed in memory, and then the entire two-phase commit is performed. In some examples, pseudocode 1122 can be executed as an optimistic transaction. Pseudocode 1122 may include one or more additional operations. The operations of pseudocode 1122 can be executed in different orders. One or more operations in pseudocode 1122 can be optional. Pseudocode 1122 can be executed by client device 102, message transceiver server system 108, and / or another device. Part of the functionality can be executed on a server computer or host.

[0138] Figure 12 Method 1200 for performing a two-phase transaction is shown, based on some examples. Method 1200 begins with operation 1202, in which the transaction is pre-validated. For example, operation 704 of method 700 performs the pre-validation of the transaction, in which the partitions 800 involved in the transaction are checked to see if they have been unlocked.

[0139] Method 1200 continues at operation 1204, where first metadata is written to the leader partition. The first metadata includes an indication of the prepared state and the transaction changes. For example, operation 706 sets the state 910 of UserA 904 to prepared and sets the change 912 of UserA 904 to "UserA.type = Friend; UserC.type = Friend".

[0140] Method 1200 continues at operation 1206, where second metadata of the follower partition is written to indicate that the follower partition is locked by the leader partition. For example, operation 708 of method 700 sets the metadata of all follower partitions to be locked by the leader partition. See reference. Figure 9 For example, transaction 919 of UserC 906 is set to "Locked: UserA".

[0141] Method 1200 continues at operation 1208, where the state of the first metadata is updated to indicate that it has been committed and a transaction is executed on the leader partition. For example, Figure 7 Operation 710 changes the leader partition's metadata state to committed and applies the transaction to the leader partition. (See also...) Figure 9 In the example, UserA 904's status 910 is changed to submitted, and UserA / UserC: type is set to friend.

[0142] Method 1200 continues at operation 1210, where a transaction is performed on the follower partition and the follower partition is unlocked. For example, operation 712 of method 700 performs a transaction on all follower partitions, unlocks the follower partitions, and sets the metadata state to committed but not applied. See reference. Figure 9 In the example, UserC / UserA: type 920 is set to friend, and transaction 919 is set to nil.

[0143] Method 1200 continues at operation 1212, where the first metadata is updated to remove the transaction's changes, and the state of the first metadata is updated to indicate that the transaction has been completed. For example, operation 714 of method 700 changes the leader partition metadata state to nil and removes the changes from the metadata. See reference. Figure 9 In the example, state 910 is set to nil, and change 912 is set to nil.

[0144] Method 1200 may include one or more additional operations. The operations of method 1200 may be performed in different orders. One or more operations of method 1200 may be optional. Method 1200 may be performed by client device 102, message transceiver server system 108, and / or another device. A portion of the functionality may be performed on a server computer or host.

[0145] Machine architecture

[0146] Figure 13This is a schematic representation of machine 1300, within which instructions 1310 (e.g., software, program, application, app, or other executable code) can be executed to cause machine 1300 to perform any or more of the methods discussed herein. For example, instructions 1310 can cause machine 1300 to perform any or more of the methods described herein. Instructions 1310 transform a general, unprogrammed machine 1300 into a specific machine 1300 programmed to perform the described and illustrated functions in the described manner. Machine 1300 can operate as a standalone device or can be coupled (e.g., networked) to other machines. In a networked deployment, machine 1300 can operate as a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Machine 1300 may include, but is not limited to, server computers, client computers, personal computers (PCs), tablet computers, laptop computers, netbooks, set-top boxes (STBs), personal digital assistants (PDAs), entertainment media systems, cellular phones, smartphones, mobile devices, wearable devices (e.g., smartwatches), smart home devices (e.g., smart appliances), other smart devices, web devices, network routers, network switches, network bridges, or any machine capable of sequentially or otherwise executing instructions 1310 specifying actions to be taken by machine 1300. Furthermore, although only a single machine 1300 is shown, the term "machine" should also be considered as a collection of machines that individually or jointly execute instructions 1310 to perform any or more of the methods discussed herein. For example, machine 1300 may include client device 102 or any of a plurality of server devices forming part of message transceiver server system 108. In some examples, machine 1300 may also include both client and server systems, wherein certain operations of a particular method or algorithm are performed on the server side and certain operations of said particular method or algorithm are performed on the client side.

[0147] Machine 1300 may include a processor 1304, a memory 1306, and an input / output (I / O) unit 1302 that can be configured to communicate with each other via a bus 1340. In the example, processor 1304 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processors 1308 and 1312 that execute instruction 1310. The term "processor" is intended to include multi-core processors, which may include two or more independent processors (sometimes referred to as "cores") capable of executing instructions simultaneously. Although Figure 13 Multiple processors 1304 are shown, but machine 1300 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

[0148] Memory 1306 includes main memory 1314, static memory 1316, and storage cells 1318, all of which are accessible by processor 1304 via bus 1340. Main memory 1306, static memory 1316, and storage cells 1318 store instructions 1310 that implement any one or more of the methods or functions described herein. Instructions 1310 may also reside wholly or partially within main memory 1314, static memory 1316, machine-readable medium 1320 within storage cell 1318, at least one processor of processor 1304 (e.g., within the processor's cache memory), or any suitable combination thereof during execution by machine 1300.

[0149] I / O component 1302 may include various components for receiving input, providing output, generating output, sending information, exchanging information, capturing measurement results, etc. The specific I / O component 1302 included in a particular machine will depend on the type of machine. For example, a portable machine such as a mobile phone may include a touch input device or other such input mechanism, while a headless server machine is unlikely to include such a touch input device. It should be recognized that I / O component 1302 may include... Figure 13Many other components are not shown. In various examples, I / O component 1302 may include user output component 1326 and user input component 1328. User output component 1326 may include visual components (e.g., displays such as plasma display panels (PDPs), light-emitting diode (LED) displays, liquid crystal displays (LCDs), projectors, or cathode ray tube (CRT) displays), acoustic components (e.g., speakers), haptic components (e.g., vibration motors, resistance mechanisms), other signal generators, etc. User input component 1328 may include alphanumeric input components (e.g., keyboards, touchscreens configured to receive alphanumeric input, optical keyboards, or other alphanumeric input components), point-based input components (e.g., mice, touchpads, trackballs, joysticks, motion sensors, or other pointing instruments), haptic input components (e.g., physical buttons, touchscreens or other haptic input components that provide the position and force of a touch or touch gesture), audio input components (e.g., microphones), etc.

[0150] In other examples, I / O component 1302 may include biometric component 1330, motion component 1332, environmental component 1334, or position component 1336, as well as a wide range of other components. For example, biometric component 1330 includes components for detecting expressions (e.g., hand expressions, facial expressions, vocal expressions, body posture, or eye tracking), measuring biosignals (e.g., blood pressure, heart rate, body temperature, sweating, or brain waves), and identifying people (e.g., voice recognition, retinal recognition, facial recognition, fingerprint recognition, or EEG-based recognition). Motion component 1332 includes accelerometer components (e.g., accelerometers), gravity sensor components, and rotation sensor components (e.g., gyroscopes).

[0151] The environmental component 1334 includes, for example, one or more camera devices (with still image / photograph and video capabilities), lighting sensor components (e.g., photometers), temperature sensor components (e.g., one or more thermometers for detecting ambient temperature), humidity sensor components, pressure sensor components (e.g., barometers), acoustic sensor components (e.g., one or more microphones for detecting background noise), proximity sensor components (e.g., infrared sensors for detecting nearby objects), gas sensors (e.g., gas detection sensors for detecting the concentration of hazardous gases for safety purposes or for measuring pollutants in the atmosphere), or other components that can provide indications, measurements, or signals corresponding to the surrounding physical environment.

[0152] Regarding the camera device, client device 102 may have a camera device system including, for example, a front-facing camera on the front surface of client device 102 and a rear-facing camera on the rear surface of client device 102. The front-facing camera may be used, for example, to capture still images and videos (e.g., “selfies”) of the user of client device 102, which can then be enhanced with the aforementioned enhancement data (e.g., filters). For example, the rear-facing camera may be used to capture still images and videos in a more conventional camera device mode, wherein these images are similarly enhanced with enhancement data. In addition to the front-facing and rear-facing cameras, client device 102 may also include a 360° camera for capturing 360° photos and videos.

[0153] Furthermore, the camera system of the client device 102 may include dual rear cameras (e.g., a main camera and a depth-sensing camera), or even include triple, quadruple, or quintuple rear camera configurations on the front and rear sides of the client device 102. For example, these multi-camera systems may include wide-angle cameras, ultra-wide-angle cameras, telephoto cameras, macro cameras, and depth sensors.

[0154] The position component 1336 includes a positioning sensor component (e.g., a GPS receiver component), an altitude sensor component (e.g., an altimeter or barometer that detects air pressure and from which altitude can be obtained), an orientation sensor component (e.g., a magnetometer), and the like.

[0155] Various technologies can be used to achieve communication. I / O component 1302 also includes a communication component 1338 operable to couple machine 1300 to network 1322 or device 1324 via a suitable coupling or connection. For example, communication component 1338 may include a network interface component or another suitable device that interfaces with network 1322. In other examples, communication component 1338 may include a wired communication component, a wireless communication component, a cellular communication component, a near field communication (NFC) component, or Bluetooth. ® Components (e.g., Bluetooth) ® Low energy consumption), Wi-Fi ® Components, and other communication components for providing communication via other means. Device 1324 can be any peripheral device from another machine or various peripheral devices (e.g., a peripheral device coupled via USB).

[0156] Furthermore, the communication component 1338 can detect identifiers, or include components operable to detect identifiers. For example, the communication component 1338 may include a radio frequency identification (RFID) tag reader component, an NFC smart tag detection component, an optical reader component (e.g., an optical sensor for detecting one-dimensional barcodes such as Universal Product Code (UPC) barcodes, multi-dimensional barcodes such as Quick Response (QR) codes, Aztec codes, data matrices, data symbols, MaxiCode, PDF417, Ultra Code, UCC RSS-2D barcodes, and other optical codes), or an acoustic detection component (e.g., a microphone for identifying audio signals from the tag). Additionally, various information can be obtained via the communication component 1338, such as location via Internet Protocol (IP) geolocation, location via Wi-Fi® signal triangulation, location via detection of NFC beacon signals that can indicate a specific location, etc.

[0157] Various memories (e.g., main memory 1314, static memory 1316, and the memory of processor 1304) and storage units 1318 may store one or more sets of instructions and data structures (e.g., software) implemented or used by any one or more of the methods or functions described herein. These instructions (e.g., instruction 1310) cause various operations to implement the disclosed examples when executed by processor 1304.

[0158] Instructions 1310 can be sent or received over network 1322 via a transmission medium using a network interface device (e.g., a network interface component included in communication component 1338) and using any of several known transmission protocols (e.g., Hypertext Transfer Protocol (HTTP)). Similarly, instructions 1310 can be sent or received via a transmission medium coupled to device 1324 (e.g., peer-to-peer coupling).

[0159] Software Architecture

[0160] Figure 14 This is a block diagram 1400 illustrating a software architecture 1404 that can be installed on any one or more of the devices described herein. The software architecture 1404 is supported by hardware such as a machine 1402 including a processor 1420, memory 1426, and I / O components 1438. In this example, the software architecture 1404 can be conceptualized as a stack of layers, where each layer provides specific functionality. The software architecture 1404 includes layers such as an operating system 1412, libraries 1410, frameworks 1408, and applications 1406. Operationally, application 1406 activates API call 1450 via the software stack and receives message 1452 in response to API call 1450.

[0161] Operating system 1412 manages hardware resources and provides public services. Operating system 1412 includes, for example, a kernel 1414, services 1416, and drivers 1422. Kernel 1414 acts as an abstraction layer between the hardware layer and other software layers. For example, kernel 1414 provides memory management, processor management (e.g., scheduling), component management, networking and security settings, and other functions. Services 1416 can provide other public services to other software layers. Drivers 1422 are responsible for controlling or interfacing with the underlying hardware. For example, drivers 1422 may include display drivers, camera drivers, BLUETOOTH® or BLUETOOTH® low-power drivers, flash memory drivers, serial communication drivers (e.g., USB drivers), Wi-Fi® drivers, audio drivers, power management drivers, etc.

[0162] Library 1410 provides common low-level infrastructure used by application 1406. Library 1410 may include system library 1418 (e.g., the C standard library), which provides functions such as memory allocation, string manipulation, and mathematical functions. Additionally, library 1410 may include API library 1424, such as media libraries (e.g., libraries for supporting the rendering and manipulation of various media formats, such as Moving Picture Experts Group-4 (MPEG4), Advanced Video Coding (H.264 or AVC), Moving Picture Experts Group Layer-3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codec, Joint Picture Experts Group (JPEG or JPG), or Portable Web Graphics (PNG)), graphics libraries (e.g., the OpenGL framework for rendering graphic content on a display in two-dimensional (2D) and three-dimensional (3D) formats), database libraries (e.g., SQLite, which provides various relational database functions), web libraries (e.g., WebKit, which provides web browsing capabilities), and so on. Library 1410 may also include various other libraries 1428 for providing many other APIs to application 1406.

[0163] Framework 1408 provides common high-level infrastructure for use by application 1406. For example, framework 1408 provides various graphical user interface (GUI) functions, advanced resource management, and advanced location services. Framework 1408 can provide a wide range of other APIs that can be used by application 1406, some of which may be specific to a particular operating system or platform.

[0164] In the example, application 1406 may include home application 1436, contacts application 1430, browser application 1432, book reader application 1434, location application 1442, media application 1444, messaging application 1446, game application 1448, and a wide variety of other applications such as third-party application 1440. Application 1406 is a program that performs the functions defined in the program. One or more applications 1406 can be created using various programming languages, such as object-oriented programming languages ​​(e.g., Objective-C, Java, or C++) or procedural programming languages ​​(e.g., C or assembly language). In a particular example, third-party application 1440 (e.g., an application developed by an entity other than a platform vendor using the Android™ or iOS™ Software Development Kit (SDK)) may be mobile software that runs on a mobile operating system such as iOS™, Android™, Windows® Phone, or another mobile operating system. In this example, a third-party application 1440 can activate API calls 1450 provided by the operating system 1412 to facilitate the functionality described herein.

[0165] Processing components

[0166] Now turn to Figure 15 , Figure 15 A schematic representation of a processing environment 1500 is shown, which includes processor 1502, processor 1506, and processor 1508 (e.g., GPU, CPU, or a combination thereof).

[0167] Processor 1502 is shown coupled to power supply 1504 and includes (permanently configured or temporarily instantiated) modules, namely a two-phase commit component 1510 and a partition access component 1512. Two-phase commit component 1510 provides decentralized access to data partitions. According to some examples, two-phase commit component 1510 implements the functionality of two-phase commit modules 614, 616, and 617. According to some examples, two-phase commit component 1510 is configured to execute methods 700, 1000, and 1200. Partition access component 1512 provides access to partitions. For example, partition access component 1512 can implement an application programming interface for a database or data repository. Partition access component 1512 can provide... Figure 1 and Figure 6 The functions of database server 120.

[0168] Glossary

[0169] "Carrier signal" refers to any intangible medium capable of storing, encoding, or carrying instructions to be executed by a machine, and includes digital or analog communication signals or other intangible media to facilitate the communication of such instructions. Instructions can be sent or received over a network using a transmission medium via a network interface device.

[0170] "Client device" refers to any machine that interfaces with a communication network to obtain resources from one or more server systems or other client devices. Client devices can be, but are not limited to, mobile phones, desktop computers, laptop computers, portable digital assistants (PDAs), smartphones, tablet computers, ultrabooks, netbooks, laptop computers, multiprocessor systems, microprocessor-based or programmable consumer electronics, game consoles, set-top boxes, or any other communication device that a user can use to access the network.

[0171] "Communications network" refers to one or more parts of a network, which can be an ad hoc network, intranet, extranet, virtual private network (VPN), local area network (LAN), wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), the Internet, a part of the Internet, a part of the Public Switched Telephone Network (PSTN), a Common Old-Style Telephone Service (POTS) network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, a network or part of a network may include a wireless network or a cellular network, and the coupling may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile Communications (GSM) connection, or other types of cellular or wireless coupling. In this example, coupling can implement any data transmission technology of various types, such as single-carrier radio transmission technology (1xRTT), evolved data optimization (EVDO) technology, general packet radio service (GPRS) technology, enhanced data rate GSM evolution (EDGE) technology, the 3rd Generation Partnership Project (3GPP) including 3G, fourth-generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA), Global Microwave Access Interoperability (WiMAX), Long Term Evolution (LTE) standards, other data transmission technologies defined by various standards setting organizations, other long-distance protocols, or other data transmission technologies.

[0172] A “component” refers to a device, physical entity, or logic having boundaries defined by functional or subroutine calls, branch points, APIs, or other technologies that provide partitioning or modularization for a particular processing or control function. A component can be combined with other components via its interface to perform machine processing. A component can be an encapsulated functional hardware unit designed for use with other components and can be part of a program that typically performs a specific function within a related function. A component can constitute a software component (e.g., code embodied on a machine-readable medium) or a hardware component. A “hardware component” is a tangible unit capable of performing certain operations and can be configured or arranged in some physical manner. In various examples, one or more computer systems (e.g., standalone computer systems, client computer systems, or server computer systems) or one or more hardware components (e.g., processors or processor groups) of a computer system can be configured by software (e.g., an application or application portion) to operate to perform certain operations as described herein. Hardware components can also be implemented mechanically, electronically, or in any suitable combination thereof. For example, a hardware component can include a dedicated circuit system or logic permanently configured to perform certain operations. Hardware components can be dedicated processors, such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs). Hardware components can also include programmable logic or circuit systems temporarily configured by software to perform certain operations. For example, a hardware component may include software executed by a general-purpose processor or other programmable processor. Once configured by such software, the hardware component becomes a specific machine (or a specific part of a machine) uniquely tailored to perform the configured function and is no longer a general-purpose processor. It should be recognized that the decision to implement a hardware component mechanically in a dedicated and permanently configured circuit system or in a temporarily configured (e.g., software-configured) circuit system can be made for cost and time considerations. Therefore, the phrase "hardware component" (or "hardware-implemented component") should be understood to include tangible entities, i.e., entities physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain way or perform certain operations described herein. Consider the example of a hardware component being temporarily configured (e.g., programmed), without needing to configure or instantiate each hardware component at any given time. For example, in cases where the hardware components include a general-purpose processor that is configured as a dedicated processor via software, this general-purpose processor can be configured as its own distinct dedicated processor (e.g., including different hardware components) at different times. The software accordingly configures one or more specific processors to constitute a particular hardware component at one moment and different hardware components at different times. Hardware components can provide information to and receive information from other hardware components. Therefore, the described hardware components can be considered communicatively coupled.In the presence of multiple hardware components, communication can be achieved through signal transmission between or among these hardware components (e.g., via appropriate circuitry and buses). In examples where multiple hardware components are configured or instantiated at different times, such communication between hardware components can be achieved, for example, by storing information in a memory structure accessible to the multiple hardware components and retrieving information from the memory structure. For example, a hardware component can perform an operation and store the output of that operation in a memory device communicatively coupled to it. Another hardware component can then access the memory device at a subsequent time to retrieve and process the stored output. Hardware components can also initiate communication with input or output devices and can operate on resources (e.g., collections of information). The various operations of the example methods described herein can be performed, at least in part, by one or more processors configured, either temporarily (e.g., by software) or permanently, to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented components that operate to perform one or more operations or functions described herein. As used herein, "processor-implemented component" refers to a hardware component implemented using one or more processors. Similarly, the methods described herein can be implemented at least in part by processors, where a particular processor or one or more processors are examples of hardware. For example, at least some operations of the methods can be performed by one or more processors or processor-implemented components. Furthermore, one or more processors can also operate to support the execution of related operations in a “cloud computing” environment or as a “Software as a Service” (SaaS) operation. For example, at least some operations can be performed by a group of computers (as an example of a machine including processors), where these operations are accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs). The execution of some operations can be distributed among processors, residing not only within a single machine but also deployed across multiple machines. In some examples, the processor or processor-implemented component may reside in a single geographic location (e.g., within a home environment, office environment, or server cluster). In other examples, the processor or processor-implemented component may be distributed across multiple geographic locations.

[0173] "Computer-readable storage medium" refers to both machine-readable storage media and transmission media. Therefore, these terms encompass both storage devices / media and carrier / modulated data signals. The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" refer to the same thing and can be used interchangeably in this disclosure.

[0174] A "brief message" is a message that can be accessed for a limited time. Brief messages can be text, images, videos, etc. The access time for a brief message can be set by the message sender. Alternatively, the access time can be a default setting or a setting specified by the recipient. Regardless of the setting method, the message is temporary.

[0175] "Machine storage medium" refers to one or more storage devices and media (e.g., centralized or distributed databases, and associated caches and servers) that store executable instructions, routines, and data. Therefore, this term should be considered to include, but is not limited to, solid-state memory and optical and magnetic media, including memory internal or external to the processor. Specific examples of machine storage media, computer storage media, and device storage media include: non-volatile memory, including, for example, semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), FPGAs, and flash memory devices; disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms "machine storage medium," "device storage medium," and "computer storage medium" mean the same thing and may be used interchangeably in this disclosure. The terms "machine storage medium," "computer storage medium," and "device storage medium" expressly exclude carrier waves, modulated data signals, and other such media, at least some of which are covered by the term "signal medium."

[0176] "Non-transitory computer-readable storage medium" refers to a tangible medium capable of storing, encoding, or carrying instructions that can be executed by a machine.

[0177] "Signal medium" means any intangible medium capable of storing, encoding, or carrying machine-executable instructions and including digital or analog communication signals, or other intangible medium that facilitates the communication of software or data. The term "signal medium" should be considered to include any form of modulated data signal, carrier wave, etc. The term "modulated data signal" means a signal whose characteristics are set or altered in a manner that encodes information in the signal. The terms "transmission medium" and "signal medium" mean the same thing and may be used interchangeably in this disclosure.

[0178] Example

[0179] 1. A method performed by a computing device, the method comprising:

[0180] Perform pre-validation on transactions;

[0181] Write the first metadata to the leader partition, the first metadata including indications of the prepared status and changes to the transaction;

[0182] Write the second metadata to the follower partition to indicate that the follower partition is locked by the leader partition;

[0183] Update the status of the first metadata to indicate that it has been committed and execute the transaction on the leader partition;

[0184] Execute the transaction on the follower partition and unlock the follower partition; and

[0185] Update the first metadata to remove the changes to the transaction and update the status of the first metadata to indicate that the transaction has been completed.

[0186] 2. The method according to Example 1 further includes:

[0187] Before writing the first metadata to the leader partition, select the leader partition key.

[0188] 3. The method according to Example 1 further includes:

[0189] After the transaction is executed on the follower partition, the status of the first metadata is updated to indicate that it has been committed but not applied.

[0190] 4. The method according to Example 1, wherein the transaction is a two-phase transaction.

[0191] 5. The method according to Example 1, wherein the leader partition and the follower partition are part of a data repository or database.

[0192] 6. The method according to Example 1, wherein the first metadata is stored in a row associated with the key of the leader partition, and the second metadata is stored in a row associated with the key of the follower partition.

[0193] 7. The method according to any one of Examples 1 to 6, wherein the transaction comprises a two-phase transaction, wherein a data field of the leader partition is changed, and a data field of the follower partition is changed.

[0194] 8. The method according to any one of Examples 1 to 6, wherein pre-validating the transaction includes:

[0195] It was determined that the leader partition and the follower partition were not locked.

[0196] 9. The method according to any one of Examples 1 to 6, wherein the state of updating the first metadata to indicate that it has been committed and the transaction is performed on the leader partition atomically, and wherein the transaction is performed on the follower partition atomically and the follower partition is unlocked.

[0197] 10. According to any one of Examples 1 to 6, updating the state of the first metadata to indicate that it has been committed and performing the transaction on the leader partition further includes: updating the value of the version of the leader partition, and wherein performing the transaction on the follower partition and unlocking the follower partition further includes: updating the value of the version of the follower partition.

[0198] 11. The method according to any one of Examples 1 to 6, wherein pre-validating the transaction further includes:

[0199] Store the version of the follower partition; and

[0200] Store the version of the leader partition.

[0201] 12. The method according to Example 11, wherein writing first metadata, including indications of the prepared state and changes to the transaction, to the leader partition further includes:

[0202] Access the version of the follower partition, and if the version is not the same as the storage version of the follower partition, abort the method.

[0203] 13. The method according to Example 11, wherein writing second metadata to the follower partition to indicate that the follower partition is locked by the leader partition further includes:

[0204] Access the version of the leader partition, and if the version is not the same as the storage version of the leader partition, abort the method.

[0205] 14. The method according to any one of Examples 1 to 6, wherein performing the transaction on the leader partition comprises:

[0206] Setting the field in the leader partition to a first new value, and wherein performing the transaction on the follower partition further includes:

[0207] Set the field in the follower partition to a second new value.

[0208] 15. The method according to any one of Examples 1 to 6, wherein the follower partition is a first follower partition, and wherein the method further comprises:

[0209] Write third metadata to the second follower partition to indicate that the second follower partition is locked by the leader partition; and

[0210] Execute the transaction on the second follower partition and unlock the second follower partition.

[0211] 16. The method according to any one of Examples 1 to 6 further includes:

[0212] Access the partition's metadata;

[0213] The metadata of the partition indicates that the partition is locked in a committed state;

[0214] Execute the second transaction indicated in the metadata of the partition; and

[0215] Unlock the partition.

[0216] 17. A first computing device, comprising:

[0217] Processor; and

[0218] A memory storing instructions that, when executed by the processor, configure the first computing device to perform operations, the operations including:

[0219] Perform pre-validation on transactions;

[0220] Write the first metadata to the leader partition, the first metadata including indications of the prepared status and changes to the transaction;

[0221] Write the second metadata to the follower partition to indicate that the follower partition is locked by the leader partition;

[0222] Update the status of the first metadata to indicate that it has been committed and execute the transaction on the leader partition;

[0223] Execute the transaction on the follower partition and unlock the follower partition; and

[0224] Update the first metadata to remove the changes to the transaction and update the status of the first metadata to indicate that the transaction has been completed.

[0225] 18. The first computing device according to Example 17, wherein the operation further includes:

[0226] Before writing the first metadata to the leader partition, select the leader partition key; and

[0227] After the transaction is executed on the follower partition, the status of the first metadata is updated to indicate that it has been committed but not applied, wherein the transaction is a two-phase transaction, and wherein the leader partition and the follower partition are part of a data repository or database.

[0228] 19. A non-transitory computer-readable storage medium, the computer-readable storage medium comprising instructions that, when executed by a first computing device, cause the computer to perform an operation, the operation comprising:

[0229] Perform pre-validation on transactions;

[0230] Write the first metadata to the leader partition, the first metadata including indications of the prepared status and changes to the transaction;

[0231] Write the second metadata to the follower partition to indicate that the follower partition is locked by the leader partition;

[0232] Update the status of the first metadata to indicate that it has been committed, and execute the transaction on the leader partition;

[0233] Execute the transaction on the follower partition and unlock the follower partition; and

[0234] Update the first metadata to remove the changes to the transaction, and update the status of the first metadata to indicate that the transaction has been completed.

[0235] 20. The non-transitory computer-readable storage medium according to Example 19, wherein the operation further includes:

[0236] Before writing the first metadata to the leader partition, select the leader partition key; and

[0237] After the transaction is executed on the follower partition, the status of the first metadata is updated to indicate that it has been committed but not applied, wherein the transaction is a two-phase transaction, and wherein the leader partition and the follower partition are part of a data repository or database.

Claims

1. A computing device, comprising: One or more processors; as well as One or more memories, the one or more memories storing instructions that, when executed by the one or more processors, configure the computing device to perform operations, the operations including: Access the partition; It is determined that the partition is locked by a transaction; Complete the transaction, which includes metadata indicating changes to the transaction; and Access the partition to read or write data.

2. The computing device according to claim 1, wherein, The transaction is the first transaction, the metadata is the first metadata, the partition is the leader partition, and the completion of the transaction further includes: The status of the first metadata is determined to be submitted; If the transaction is not executed, then the transaction indicated by the first metadata is executed; Execute the transaction on the follower partition and unlock the follower partition; The first metadata is updated to remove the changes to the transaction and the status of the first metadata is updated to indicate that the transaction has been completed, wherein the leader partition and the follower partition are different parts of a data repository or database.

3. The computing device according to claim 2, wherein, The transaction is executed atomically on the follower partition and the follower partition is unlocked.

4. The computing device according to claim 2, wherein, The operation also includes: Access the version of the follower partition, and abort if the version is not the same as the storage version of the follower partition.

5. The computing device according to claim 1, wherein, The transaction is the first transaction, the metadata is the first metadata, the partition is the leader partition, and the completion of the transaction further includes: The status of the first metadata is determined to be "preparing". Update the status of the transaction on the follower partition to complete and unlock the follower partition; The first metadata is updated to remove the changes to the transaction and the status of the first metadata is updated to indicate that the transaction has been completed, wherein the leader partition and the follower partition are different parts of a data repository or database.

6. The computing device according to any one of claims 1 to 5, wherein, The transaction is the first transaction, and the completion of the transaction further includes: Determine that the first transaction is on the leader partition; The status indication of the first transaction has been determined to be committed; In response to the first transaction not being completed, complete the first transaction as indicated by the change in the first transaction; and Update the status of the first transaction to "committed but not applied".

7. The computing device according to claim 6, wherein, The operation also includes: Find the second transaction on the follower partition; Update the status of the second transaction to complete; and Update the status of the first transaction to "completed".

8. The computing device according to any one of claims 1 to 5, wherein, The transaction is the first transaction, the metadata is the first metadata, the partition is the follower partition, and the completion of the transaction further includes: It is determined that the first transaction is locked by the leader partition, the leader partition including second metadata; The status of the second metadata is determined to be submitted; If the transaction is not executed, then the transaction indicated by the second metadata is executed; Execute the transaction on the follower partition and unlock the follower partition; The second metadata is updated to remove the changes to the transaction and the status of the second metadata is updated to indicate that the transaction has been completed, wherein the leader partition and the follower partition are different parts of the data repository or database.

9. The computing device according to any one of claims 1 to 5, wherein, The transaction is a two-phase transaction.

10. A method performed by a computing device, the method comprising: Access the partition; It is determined that the partition is locked by a transaction; Complete the transaction, which includes metadata indicating changes to the transaction; as well as Access the partition to read or write data.

11. The method according to claim 10, wherein, The transaction is the first transaction, the metadata is the first metadata, the partition is the leader partition, and the completion of the transaction further includes: The status of the first metadata is determined to be submitted; If the transaction is not executed, then the transaction indicated by the first metadata is executed; Execute the transaction on the follower partition and unlock the follower partition; The first metadata is updated to remove the changes to the transaction and the status of the first metadata is updated to indicate that the transaction has been completed, wherein the leader partition and the follower partition are different parts of a data repository or database.

12. The method according to claim 11, wherein, The transaction is executed atomically on the follower partition and the follower partition is unlocked.

13. The method according to claim 11, wherein, The method further includes: Access the version of the follower partition, and if the version is not the same as the storage version of the follower partition, abort the method.

14. The method of claim 10, wherein, The transaction is the first transaction, the metadata is the first metadata, the partition is the leader partition, and the completion of the transaction further includes: The status of the first metadata is determined to be "preparing". Update the status of the transaction on the follower partition to complete and unlock the follower partition; The first metadata is updated to remove the changes to the transaction and the status of the first metadata is updated to indicate that the transaction has been completed, wherein the leader partition and the follower partition are different parts of a data repository or database.

15. The method according to claim 10, wherein, The transaction is the first transaction, and the completion of the transaction further includes: Determine that the first transaction is on the leader partition; The status indication of the first transaction has been determined to be committed; In response to the first transaction not being completed, complete the first transaction as indicated by the change in the first transaction; and Update the status of the first transaction to "committed but not applied".

16. A non-transitory computer-readable storage medium, the computer-readable storage medium comprising instructions that, when executed by a first computing device, cause the computer to perform an operation, the operation comprising: Access the partition; It is determined that the partition is locked by a transaction; Complete the transaction, which includes metadata indicating changes to the transaction; as well as Access the partition to read or write data.

17. The non-transitory computer-readable storage medium according to claim 16, wherein, The transaction is the first transaction, the metadata is the first metadata, the partition is the leader partition, and the completion of the transaction further includes: The status of the first metadata is determined to be submitted; If the transaction is not executed, then the transaction indicated by the first metadata is executed; Execute the transaction on the follower partition and unlock the follower partition; The first metadata is updated to remove the changes to the transaction and the status of the first metadata is updated to indicate that the transaction has been completed, wherein the leader partition and the follower partition are different parts of a data repository or database.

18. The non-transitory computer-readable storage medium according to claim 17, wherein, The transaction is executed atomically on the follower partition and the follower partition is unlocked.

19. The non-transitory computer-readable storage medium according to claim 17, wherein, The operation also includes: Access the version of the follower partition, and abort if the version is not the same as the storage version of the follower partition.

20. The non-transitory computer-readable storage medium according to claim 16, wherein, The transaction is the first transaction, the metadata is the first metadata, the partition is the leader partition, and the completion of the transaction further includes: The status of the first metadata is determined to be "preparing". Update the status of the transaction on the follower partition to complete and unlock the follower partition; The first metadata is updated to remove the changes to the transaction and the status of the first metadata is updated to indicate that the transaction has been completed, wherein the leader partition and the follower partition are different parts of a data repository or database.

Images