115 results about "Commit" patented technology

Conventional file-based engineering design data for an engineering model are represented by a plurality of components. Each component has a unique identifier, a set of fields, each field having a data type and a data value, and a program which interprets and modifies the fields. The plurality of components are stored in a repository of a server. The repository also stores a history of any changes made to the components. A plurality of client computers are bidirectionally connected to the server. Each client computer may obtain the current version of the components and may send locally edited versions of the components back to the server to replace the current versions in the repository. At the client computer, the user interacts with the components using conventional file-based software. Before locally edited versions of the components are committed to the server to replace the current versions, a synchronization and merging process occurs whereby the latest version of the components are downloaded to the client computer and are compared to the locally edited version of the components to detect resolvable (compatible) and unresolvable (incompatible) conflicts therebetween. The commit process is performed only if no unresolvable conflicts exist between the two versions of the components. To facilitate translation between file-based data and components, a schema is written to "wrap" each of the engineering file formats. Each schema is a set of classes that capture all of the information in the file-based data.

Tokens are used to prepare a target database for replication from a source database and to confirm the preparation in an asynchronous coordinated commit replication process. During a dual write replication process, transmission of the replicated data and locking of data records in the target database occurs only on updates.

An apparatus and method is described herein for providing instantaneous, efficient cache state recover upon an end of speculative execution. Speculatively accessed entries of a cache memory are marked as speculative, which may be on a thread specific basis. Upon an end of speculation, the speculatively marked entries are transitioned in parallel by a speculative port to their appropriate, thread specific, non-speculative coherency state; these parallel transitions allow for instantaneous commit or recovery of speculative memory state.

A system for implementing synchronized objects for software transactional memory comprises one or more processors and a memory comprising program instructions executable by the processor to implement a transactional-memory manager configured to coordinate memory access requests directed at the memory from a plurality of transactions. The transactional-memory manager records, within a collaborator record for a shared data object in the memory, identifications of a set of two or more transactions that have requested synchronization on the object. In response to a commit request from a given transaction of the set, the transactional-memory manager determines whether to commit or abort the given transaction based at least in part on the transactional states of other transactions in the set, examining the collaborator record to identify the other transactions.

A method and system (200) for message handling in a messaging system by: receiving messages from applications associated with transactions and placing the received messages in a queue (230) for subsequent retrieval; receiving requests of prepare, commit and abort for the transactions; deferring retrieval of messages from the queue so as to occur in the same sequence as the prepare requests of the transactions with which the respective messages are associated; and retrieving from the queue messages associated with a transaction in the order in which the messages were put by the application. Preferably deferral is achieved by deferring completion of transaction commits as required to occur in the same order as the prepare message requests. Deferral may be implemented by (i) using a three phase commit protocol having Prepare, Commit, and Release phases and by implementing the Release phase within the Commit phase of the same or a different transaction so that a standard two-phase coordinator may be used, or (ii) by completing a first part of a commit phase as requested and deferring a second part of the commit phase as required. This permits appropriate message ordering in a transactional system, and in particular permits the correct implementation of a database replication system (220) using coordinated message transport that is fed the changes during database transactions.

A transactional file system configured to realize atomic update of plural files by transactions. In the transactional file system, a log entry containing information for validating all updates made by a transaction collectively on a stable memory device, is generated for one or more files updated on a buffer region by the transaction since a start of a processing of the transaction until a commit of the transaction. Then, the log entry is written into the stable memory device at a time of the commit of the transaction.

A method repairs a table. A replication environment has a first replicate comprising a source table on a source server and a target table on a target server. The source server transmits replication data from the source server with repair data from the source server to the target table in accordance with a commit order of the replication data and the repair data. The target server applies the repair data and the replication data to the target table based on the commit order.

Conventional file-based engineering design data for an engineering model are represented by a plurality of components. The plurality of components are kept in stores, which reside on servers. Each store contains the components that correspond to the elements of one design file. The stores also maintain a history of changes made to the components. A plurality of client computers are bidirectionally connected to the servers. Each client computer may obtain the current version of the components and may send locally edited versions of the components back to the servers to replace the current versions in the stores. At the client computer, the user interacts with the components using conventional file-based software. Before the locally edited versions of the components are committed to the servers to replace the current versions, a synchronization and merging process occurs whereby the latest version of the components are downloaded to the client computer and are compared to the locally edited version of the components to detect resolvable (compatible) and unresolvable (incompatible) conflicts. The commit process is performed only if no unresolvable conflicts exist between the two versions of the components. To facilitate translation between file-based data and components, a schema is written to “wrap” each of the engineering file formats. Each schema is a set of classes that capture all of the information in the file-based data.

The invention discloses a heterogeneous-database-replication parallel execution system and method based on synchronization of commit-point timelines. The system includes a source database, a target database and a replication system. The system and method have the advantages that for preventing destination-end events from execution failure, a traditional data replication system based on logs serially executes logs of various events according to the time sequences (LSN numbers) of the logs and does not consider the probability of the parallel execution of events. According to the system and method, commit-point timelines are adopted to form fences, the characteristic that all upload operations between two timelines do not colloid with one another is adopted, the operations are executed at the destination end in parallel, the replication efficiency is greatly improved, and the technical problem of the low replication efficiency caused by the serial execution of events in the target database is solved.

An extractor and an applier of a database replication system are configured to perform the functions of resolving constraint violations for replicated database transactions. The extractor replicates changes made at the source database to the target database. An applier immediately applies the changes to the target database that do not cause a constraint violation. The applier also performs the remaining functions, including detecting database changes that cause constraint violations, subsequent processing of these detected database changes, and performing a commit for the database transaction when the constraint violations are resolved.

Disclosed herein are an apparatus and method for achieving distributed consensus based on decentralized Byzantine fault tolerance. The apparatus may include one or more processors and an execution memory for storing at least one program that is executed by the one or more processors, wherein the program is configured to receive delegate request messages, each including a first transaction for requesting distributed consensus proposed by a client, and determine congress candidate nodes forming a consensus quorum, to be consensus nodes based on the delegate request messages, generate a prepare message that includes a second transaction for obtaining consent to results of determination of the consensus nodes, and send the prepare message to the consensus nodes, and receive commit messages, each including an electronic signature of a corresponding consensus node, from the respective consensus nodes, and broadcast a reply message indicative of results of verification of the electronic signatures.

Data can be replicated over a network using a one or two phase method. For the one phase method, a master server containing an original copy of the data sends a version number for the current state of the data to each slave on the network so that each slave can request a delta from the master. The delta that is requested contains the data necessary to update the slave to the appropriate version of the data. For the two phase method, the master server sends a packet of information to each slave. The packet of information can be committed by the slaves if each slave is able to process the commit.

A global transaction system receives a transaction request for a plurality of database services of microservices. The global transaction system receives a plurality of local commit decisions of local commit requests from local transaction managers of the database services of the microservices. The local commit request corresponds to the transaction request for each database. The global transaction system generates a physical commit request to each of the local transaction managers based on the local commit decisions and a global commit decision. Each local transaction manager submits the physical commit request to each database server of the database services corresponding to the transaction request.

Embodiments of the present disclosure provide a method, a computer program product and apparatus for processing transactions in a synchronized replication system, wherein the method comprises, at a source site in the synchronized replication system: serializing commits of transactions in the synchronized replication system so that only one of the transactions can be committed at the same time; in response to initiating the commit of the one transaction, generating a log for each of transactions that are ongoing in the synchronized replication system, so as to record impact of all operations of a respective transaction on the synchronized replication system; marking transactions for which the logs have been generated; and completing commits of the marked transactions.

One embodiment of the present invention provides a system which decouples register bypassing from pipeline depth. The system starts by storing an intermediate result generated by an originating instruction to an allocated location in an architectural-commit first-in-first-out (ACFIFO) structure and to an allocated location in a working register file (WRF). The system then bypasses the intermediate result from the WRF to subsequent dependent instructions until the originating instruction retires from the instruction execution pipeline. Next, the system stores the intermediate result from the ACFIFO structure to a location in an ARF when the originating instruction retires from the instruction execution pipeline. The system then removes the intermediate result from the WRF and the ACFIFO structure when the intermediate result has been stored in the ARF.

The invention discloses a blockchain consensus method and system, a computer storage medium and electronic equipment, and the method comprises the steps: Block N + 1 enters a Propose stage after the consensus of a block Block N enters a Confirmware stage; after the Block N enters the Commit stage, the Block N + 1 enters the Confire stage, and the Block N + 2 enters the Propose stage; wherein the Block N, the Block N + 1 and the Block N + 2 are executed in sequence; in the concurrent consensus process, after the previous block completes a certain stage, the next block starts the stage; after the current round of concurrent consensus is completed, setting the block BlockN + 2 of which the latest consensus is completed as a stable block; wherein the next round of concurrent consensus starts from the stable block. Consensus flows of multiple blocks are processed concurrently, so that the consensus performance is improved, and an additional Checkpoint mechanism is not needed.

The invention relates to the technical field of block chains, and discloses a Byzantine fault tolerance optimization method based on aggregate signatures and a storage medium, and the method comprisesthe steps: S1, a Pre-Prepreme stage: a main node collects transactions in a transaction memory pool, packages the transactions into blocks, and broadcasts the blocks to all replica nodes for consensus; S2, a Prepare stage: after receiving the Prepare message sent by the main node, all the replica nodes send back a Prepare message to the main node; S3, a Commit stage: the main node verifies each Prepart information, verifies the signature of the replica node, aggregates the signatures passing the verification into a signature through a BLS signature, and broadcasts the aggregated signature andother necessary information to all other replica nodes for verification; and the copy node links the block to the chain tail of the block chain to finish synchronization after verifying that the copynode is correct according to the received Commit message. The problem that an existing Byzantine fault-tolerant protocol is not suitable for large-scale node consensus is solved.

A data processing system comprises at least one resource manager (RM) for managing changes to respective system resources in accordance to a commit / backout protocol, and a resource manager coordinator (RMC) for coordinating the commit / backout activities of the at least one resource manager. A process resource manager (ERM) is provided, coordinated by the resource manager coordinator according to the commit / backout protocol, for managing the execution of non-compliant processes not complying with the commit / backout protocol. The process resource manager automatically determines, upon receipt of a backout request, a sequence of compensation actions to be performed to backout actions performed during the execution of the secondary non-compliant processes, and managing the execution of said compensation actions.

A method of calculating a failure probability of a change in one or more source code repositories comprises analyzing at least one commit made to the source code repositories, determining a type of the commit selected from a fixing commit and a new code commit, if the commit is a new code commit, determining a set of areas of source code modified, if the code is a fixing commit, determining which commit of a plurality of new code commits is the causing commit, analyzing the commit message and calculating one or more parameters of the commit message, training a machine learning classifier with the set of data, and using the machine learning classifier to calculate a probability that the commit will cause a failure in the source code repository. Methods and systems for task assignment and test selection are also described.

A method is provided for performing transaction processing in a system that includes a transaction distributor and a plurality of nodes. Each of the nodes include a processor, an application executing in the processor, and an instance of a database used by the application. Each node executes transactions. The transaction distributor selects at least two of the nodes to receive the same request to process a transaction, and the processor at each of the at least two nodes executes the same request to process a transaction. Each of the at least two nodes replicates to one or more other nodes in the system the steps and operations of the transactions up until a transaction END step. The processor at the one or more other nodes compares the replicated steps and operations of the transactions that were received from each of the at least two nodes and performs a transaction END step for the replicated transaction at the one or more other nodes in the system by either executing a COMMIT when the result of the comparison indicates that the replicated steps and operations of the replicated transactions match each other, or executing an ABORT when the result of the comparison indicates that the replicated steps and operations of the replicated transactions do not match each other.

The invention discloses a parallelization Byzantine fault tolerance method applied to a blockchain consensus mechanism, and the consensus algorithm comprises a plurality of consensus partitions running in parallel at a bottom layer and independent verification partitions running at an upper layer, and the consensus partitions and the independent verification partitions jointly form a layered parallelization consensus verification system. The underlying consensus partitions respectively, independently and parallelly receive task requests (a pre-preparation stage, namely a Pre-prepare stage); and then, a message request service (a preparation stage, namely a Prepart stage) is executed, and meanwhile, signature of an execution result is achieved by adopting an aggregation signature algorithmin an execution process so as to achieve the purposes of reducing message complexity and improving system throughput. Besides, according to the algorithm design, the Commit stage message of the current consensus process and the Prepare stage message of the next consensus process are combined and sent, so that the purposes of compressing the communication rounds and reducing the communication overhead are achieved, the throughput of the system is further improved, and the average time delay is reduced.

A method and apparatus for a mechanism of disaster recovery and instance refresh in an event recordation system are described. A first request for events associated with a first topic is received. A first set of events associated with the first topic are retrieved from a primary event recordation system. Each event from the first set of events includes a first commit identifier indicating the order with which each event is stored in the primary event recordation system. For each event from the first set of events a first replay identifier is determined based on the first commit identifier and a first value of a low commit identifier. The first replay identifier is exposed to event consumers for identifying the event. In response to the first request each event from the first set of events is transmitted with the replay identifier.

Techniques for replicating data to a database include determining a change to at least one database value in a database table on a source repository; updating, based on the change to the at least one database value, a snapshot value associated with the change to the at least one database value stored in a log table; incrementing a commit value associated with the snapshot value stored in a commit table, the commit table comprising a plurality of commit values associated with a plurality of corresponding snapshot values; initiating replication of the database from the source repository to a target repository; determining a maximum commit value of the plurality of commit values; and replicating the database value in the database table from the source repository to the target repository based on the commit value associated with the snapshot value being less than or equal to the maximum commit value.

A method and a system for detecting an occurrence of an auto-commit operation applied to files managed by a file server compliant with write-once-read-many (WORM) rules. The method includes: allocating a plurality of non-overlapping predefined time ranges starting from a newest-changed-files time range and ending at an oldest-changed-files time range, wherein the time ranges add up to an auto-commit period associated with the auto-commit operation; repeatedly updating a count of files whose file-change-time is associated respectively with one of the allocated time ranges, wherein the updating is carried out every time the predefined time range lapses; and detecting, every time the time range lapses, an occurrence of an auto-commit operation applied to at least one of the files stored on the volume within a duration of the time range since the updating, whenever the count of the files associated with the oldest-changed-files time range is non-zero.

In a distributed database, a transaction is to be committed at a first coordinator server and one or more participant servers 1210. The first coordinator server is configured to receive a notificationthat each participant server of the transaction is prepared at a respective prepared timestamp, the respective prepared timestamp being chosen within a time range for which the respective participantserver obtained at least one lock 1220. The first coordinator server computes the commit timestamp for the transaction equal or greater than each of the prepared timestamps 1230, and restrict the commit timestamp such that a second coordinator server sharing at least one of the participant servers for one or more other transactions at a shared shard cannot select the same commit timestamp for anyof the other transactions 1240. The transaction is committed at the commit timestamp 1250.

Provided are a blockchain consensus method and system, and a computer-readable storage medium, which are used for solving the technical problem that it takes a long time to execute a PBFT algorithm. The blockchain consensus method includes: an Nth proposer node initiating an Nth proposer request, so as to generate an Nth block and broadcast the Nth block according to the Nth proposer request, wherein the Nth block having a height of n, N and n being positive integers; an (N+1)th proposer node initiating an (N+1)th proposer request after receiving the Nth block, so as to generate an (N+1)th block and broadcast the (N+1)th block according to the (N+1)th proposer request, the (N+1)th block having a height of n+1; and after the Nth block ends a commit step, the (N+1)th block entering a commit step.

A method and system provide the ability to manage data. Property sets consisting of property set objects are created based on a schema that defines a type and a version of the objects. The property sets are organized hierarchically to form a property tree. A commit graph stores the property set objects via an append only data structure. The commit graph provides a topology of changes between states of the objects as commit nodes organized as parent commit nodes and child commit nodes. Change sets represent a change between two commit nodes. Each change set tracks changes made on the objects, and the changes specify permitted basic operations including insert, remove, or modify operations that are applied on each state to get to a next state of the objects.

A submission data managing system includes a submission data storing unit, a list screen supplying unit and a submission data supplying unit. The submission data storing unit stores a submission data and a class data, wherein the submission data is submitted by any one of members in an electronic forum, and the class data indicates any one of classes to which the submission data belongs. The list screen supplying unit outputs a list screen data to a terminal of the one of members, in response to a request for the list screen data from the terminal, wherein the list screen data indicates a list of the submission data in the one of classes stored in the submission data storing unit. The submission data supplying unit outputs the submission data to the terminal, in response to a request for the submission data selected from the list from the terminal. The class data is supplied with the submission data, the submission data storing unit relates the submission data to the class data while storing the submission data and the class data.