Parallel processing of changes in a distributed system
Parallel processing of database changes into subsections addresses inefficiencies in traditional systems, enhancing data replication performance and reliability for high-change-rate objects.
Patent Information
- Authority / Receiving Office
- DE · DE
- Patent Type
- Utility models
- Current Assignee / Owner
- Filing Date
- 2021-07-08
- Publication Date
- 2026-04-09
AI Technical Summary
Traditional database systems face inefficiencies in capturing and transmitting high-volume data changes with low latency due to sequential processing, which is inadequate for objects with high change rates and short latency requirements.
Implementing parallel processing of logged changes by dividing them into subsections, allowing simultaneous compilation and transmission to target systems while tracking and managing these subsections to avoid collisions and handle errors.
Enhances data replication performance by reducing latency and improving throughput in high-change-rate scenarios, ensuring efficient and reliable data synchronization between source and target systems.
Smart Images
Figure 00000000_0000_ABST
Abstract
Description
background
[0001] Traditional database systems store large amounts of data relating to many aspects of a business. It is often desirable to mirror specific parts of the data stored in one system (i.e., a source system) in one or more other systems (i.e., target systems). For example, it may be desirable to mirror a portion of the data stored in a source system, particularly suitable for data collection and storage, in a target system, which is particularly suitable for data analysis.
[0002] A replication server can be used to create and update target objects (such as tables or views) in a target system that mirror the corresponding source objects in a source system. The replication server can use a change-capture mechanism that runs on the source system. This mechanism has database triggers that run on the source system and identify and log changes to specific source objects. In this operation, the replication server requests changed data from the change-capture mechanism, which then compiles the logged changes and returns the compiled changes to the replication server. The replication server then applies the compiled changes to the corresponding target objects.
[0003] Traditionally, the mechanism for capturing changed data compiles the changes using a single process. Such sequential processing may be sufficient if latency requirements are low or the number of changes for a given object is small. However, sequential processing may be inadequate for objects with a high change rate and / or use cases that require short latency between changes to source objects and the propagation of those changes to a corresponding target object.
[0004] Systems to improve the performance of change compilation and the transmission of changes to a target system are desirable. Brief description of the drawings Fig. 1 is a replication architecture according to some embodiments. Fig. Figure 2 is a flowchart of the parallel processing of changes according to some embodiments. Fig. Figure 3 shows subsections or sub-sections of entries in a subscriber logging table according to some embodiments. Fig. Figure 4 is a block diagram of a subscriber system and a source system that includes a change data capture engine which implements parallel processing of changes according to some embodiments. Fig. Figure 5 is a tabular representation of performance settings according to some implementations. Fig. Figure 6 is a tabular representation of a subscriber worklist according to some embodiments. Fig. Figure 7 is a tabular representation of a subscriber logging table according to some embodiments. Fig. Figure 8 is a tabular representation of a pointer table that was last processed according to some embodiments. Fig. Figure 9 is a tabular representation of a subsection information table according to some embodiments. Fig. Figure 10 is a tabular representation of a subsection boundary table according to some embodiments. Fig. Figure 11 is a flowchart of a process for compiling and transmitting changes according to some embodiments. Fig. Figure 12 is a flowchart of a process for committing the processing of a subsection or sub-section according to some embodiments. Fig. Figure 13 is a flowchart of a process for resetting the processing of a subsection according to some embodiments. Fig. Figure 14 is a block diagram of computer devices comprising a replication architecture according to some embodiments. Detailed description
[0005] The following description is intended to enable any person skilled in the art to manufacture and use the described embodiments. However, various modifications will be readily apparent to those skilled in the art.
[0006] Some implementations provide for the parallel processing of logged changes to objects in a source system. Such parallel processing involves the parallel compilation of the logged changes and the transmission of the compiled changes to a requesting subscriber. Generally, parallel processing is achieved by dividing logged changes for a given subscriber / object combination into subsections and processing each subsection in parallel. Mechanisms for tracking the parallel processing of the subsections to avoid collisions, commit successful processing, and handle processing errors are also provided.
[0007] Fig. Figure 1 shows System 100 according to some embodiments. System 100 has a replication system 110 for replicating data from the source system 120 to the target system 130. Even if Fig. Figure 1 shows a source system and a target system, and in some embodiments the replication system 110 can replicate data from any number of source systems to any number of target systems.
[0008] In general, the replication system 110 can run the replication server 112 based on configuration data 114 to manage a replica of one or more objects (e.g., tables, views) from the source system 120 to the target system 130. The configuration data 114 can specify particular objects from a specific source system to be replicated to one or more specific target systems for a particular subscriber. Managing such replicas involves replicating records from specific data tables 127 to data tables 134.
[0009] The client device system 140 can run the client application 145 to communicate with the source system 120. According to some embodiments, the client application 145 can include code that runs in a web browser executed by the client system 140. The client application 145 can include a business application that accesses data in the data tables 127. Such access can include inserting new records, updating existing records, or deleting existing records in the data tables 127. Alternatively, the client application 145 can also provide data archiving functionality to move selected records from the data tables 127 to an archive data store (not shown).
[0010] The source system 120 can execute the replication source client 121 to record changes to objects specified in the configuration data 114 in log tables 124. In some embodiments, the replication source client 121 has database triggers to detect insert, update, and delete operations performed on records of specific data tables 127 during database transactions. In some embodiments, an individual database trigger is created for each operation on each specified table. The database triggers record the detected operations as log entries in the corresponding log tables 124. In a case where the object is a data table, the object is associated with only one log table 124.If the object is a view that selects data from more than one underlying data table, the object is associated with one logging table per underlying data table (124).
[0011] As described in detail below, log tables 124 can contain a log entry for each database record affected by a database transaction, specifying the key field values of the database record and the type of operation performed on the record. The replication source client 121 can further include an observer process that reads the log entries and writes similar log entries to subscriber log tables, each associated with a specific data table. Based on a request received from a subscriber (e.g., the replication server 112) for modified data of a specific object, a data reconstruction and transfer process of the replication source client 121 reconstructs the modified data based on the log entries and transfers the modified data to the subscriber for subsequent transfer to a target system.As mentioned above, two or more data reconstruction and data transfer processes can run in parallel to reconstruct and transfer the changed data.
[0012] Specifically, processed pointers 125 specify one or more subscriber log tables for a given subscriber and object, and for each of these subscriber log tables, a recent subscriber log table entry processed by that subscriber. Additionally, a current maximum pointer (i.e., a pointer to a recent recent entry) is known for each of the subscriber log tables. A "main body" of log table entries is determined for each of the subscriber log tables based on the processed pointers 125 and the current maximum pointers. The main body consists of all entries following the most recently processed subscriber log table entry, up to and including the recent recent entry.
[0013] To enable parallel processing of the main parts of the log table entries, each main part is divided into two or more subsections or subparts of the log table entries. The size of each subsection can be determined based on a setting corresponding to the subscriber / object combination. The division of a main part into two or more subsections according to some embodiments is described in detail below.
[0014] Section information 126 stores a status and boundaries (e.g., pointers to the first and last entry) of each subsection. In operation, data reconstruction and transfer processes use section information 126 to reconstruct and transfer data associated with each subsection in parallel, as described below.
[0015] The data stored in Tables 127 and 134 can include one or more of the following formats: conventional tabular data, row-based data, column-based data, and object-based data. According to some embodiments, the replication server 112 is configured to perform all the transformations necessary to convert data from a Table 127 format to a Table 134 format. The data may be distributed across multiple relational databases, dimensional databases, and / or other data sources.
[0016] Both the source system 120 and the target system 130 can comprise any computer system capable of running a database management system, storing and independently managing data for one or more tenants, and, in some embodiments, supporting the execution of database server applications. Each of the source systems 120 and target systems 130 can include a distributed storage system and / or distributed server nodes for performing computational operations as known in the art. According to some embodiments, the source system 120 is a local transactional database system and the target system 130 is an in-memory database system configured to provide data analytics, but embodiments are not limited to these.In this context, a client application (not shown) can communicate with one or more server applications (not shown) running on the target system 130 to perform data analysis on data stored in tables 134.
[0017] The source system 120 and the target system 130 can implement an in-memory database, in which a complete database is stored in volatile (e.g., non-disk-based) storage (e.g., main memory). The complete database can be stored and / or backed up persistently on hard disks (not shown). Implementations are not limited to in-memory. For example, the source system 120 and the target system 130 can store data in random-access storage (e.g., a cache for storing recently used data) and on one or more hard disks (e.g., persistent storage for storing their respective portions of the complete database).
[0018] Fig. Figure 2 shows process 200 for parallel replication of data changes according to some embodiments. Process 200 can be accessed via the replication source client 121 from Fig. 1 can be carried out, but the embodiments are not limited to this.
[0019] Process 200 and the other processes described herein can be executed using any suitable combination of hardware and software. Software program code embodying these processes can be stored on any non-volatile physical medium, including a hard disk, volatile or non-volatile random-access memory, DVD, flash memory, or magnetic tape, and executed by any number of processing units, including but not limited to processors, processor cores, and processor threads. Such processors, processor cores, and processor threads can be implemented by a virtual machine deployed in a cloud-based architecture. Embodiments are not limited to the examples described below.
[0020] According to some embodiments, S210 receives a request from a subscriber for changed data of an object. It is assumed that changed data of the object exists and that the process therefore continues with S220. The determination of whether changed data exists is described below according to some embodiments.
[0021] In S220, log table entries associated with the subscriber and the object are determined based on one or more pointers to recently processed log table entries. In an example from S220, subscriber log tables associated with the object are determined. The object is associated with only one subscriber log table if the object is a data table, and with more than one subscriber log table if the object is a view that selects data from more than one underlying data table.
[0022] According to some embodiments of S220, for each of the discovered subscriber log tables, a last processed pointer is determined based on the subscriber, the object, and a data structure (e.g., processed pointers 125) that specifies pointers to last processed log table entries for various combinations of subscribers, objects, and log tables. Additionally, for each of the one or more subscriber log tables, a current maximum pointer (i.e., a pointer to a recent last entry) is determined. Subsequently, in S220, for each of the one or more subscriber log tables, the log table entries are determined based on the last processed pointers and the current maximum pointers.The identified entries consist of all entries that follow the last processed subscriber log table entry, up to and including the current last entry.
[0023] Next, several subsections of the identified log table entries are defined in S230. The size of each subsection can be determined based on a maximum number of entries per subsection, which is specified for the subscriber / object combination. A subsection definition can specify a corresponding subscriber log table, a status, and pointers to the first and last entries of the subsection.
[0024] Fig. Figure 3 shows the determination of log table entries and the definition of subsections in S220 and S230 according to some embodiments. As shown, a range of log table entries 300 is determined based on the last processed pointer and a current (i.e., in S220) maximum pointer. The range is divided into subsections 1-4 according to the predefined maximum number of records per section for the respective object and subscriber. Unless the records of the range are evenly divisible by the specified maximum number of records, the last subsection (i.e., subsection 4) has fewer entries than the specified maximum number of records per section. S230 includes storing pointers to a first and a last entry of the associated subsection, along with an identifier for each subsection 1-4.
[0025] The source system continues to execute database transactions during S220 and S230, which can lead to the addition of log table entries and a corresponding increase in the maximum pointer, as described in Fig. Figure 3 shows these added log table entries (i.e., between the old maximum pointer and the current maximum pointer) are ignored during S230 and processed in a subsequent processing run.
[0026] In S240, the determined log table entries for each subsection are used to compile records according to the modified data of each subsection, as is known in the art, and the records are transmitted to the subscriber along with the subsection ID. The compilation and transmission of records associated with one subsection can occur in parallel with the compilation and transmission of records associated with at least one other subsection.
[0027] If the subscriber successfully transfers the records associated with a subsection to a target system, a call to a commit API containing the subsection ID can be received from the subscriber. In response, the subsection status in S250 is set to "completed". If the data transfer to the target system is unsuccessful, the subscriber can call a rollback API using the subsection ID. The rollback API sets the subsection status in S260 to "failed".
[0028] As described below, various cleanup mechanisms can handle updating the most recently processed pointers of the log tables and deleting log table entries of subsections once subsections have been set to the "complete" status. Other error handling mechanisms (e.g., for handling failed subsections or errors during subsection definition) are also described below.
[0029] Fig. Figure 4 shows System 400 according to some embodiments. System 400 may include an implementation of System 100, but the embodiments are not limited to this. Accordingly, embodiments of System 400 may execute Process 200.
[0030] System 400 comprises a source system 410 and a subscriber system 450. Source system 410 has a change data capture engine 420, which in turn has a data reconstruction and transfer process 421. The data reconstruction and transfer process 421 coordinates the selection of logged changes and initiates the reconstruction of data depending on the respective object type. For a database table, the data reconstruction and transfer process 421 returns complete records based on the logged key field values. For a view, the data reconstruction and transfer process 421 returns the result of the view itself based on the logged key field values, taking into account the individual association conditions and calculations of the view.After reconstruction, the data reconstruction and transfer process 421 transfers the reconstructed result to the object subscriber who requested the transfer.
[0031] As described above, the data reconstruction and transfer process 421 can operate in parallel on multiple subsections of the logged key field values. Performance settings 422 determine whether log table entries for a given object-subscriber combination are processed in parallel. In general, parallelization settings can be configured to maintain a small number of records in the respective subscriber log table, indicating a current target system. For example, small objects and / or objects with low data velocity may be associated with sequential processing, while objects that undergo many changes in a short time may be associated with parallel processing.
[0032] Performance settings 422 also specify a maximum number of records per subsection. In the case of sequential processing, the specified maximum number of records can define a maximum number of log table entries to be processed by a sequential process at any given time. The maximum number of records associated with a particular object can be set taking into account a preferred maximum amount of data to be transferred over the network at any given time. The maximum number can therefore be determined, at least in part, based on the size of each record in the object. Consequently, the maximum number associated with a table with many fields may be smaller than the maximum number associated with a table with fewer fields.
[0033] Fig. Figure 5 shows performance settings 422 according to some embodiments. Each performance setting 422 record specifies, for a particular combination of client (to accommodate a multi-tenant source system), subscriber ID, object name, and object type, a maximum number of records per subsection and a parallelization mode. The parallelization mode can specify sequential processing or one or more of the parallelization types provided by process 421.
[0034] Subscriber worklist 423 can indicate, for a specific subscriber and object, that the object has been updated since the object data was last received by the subscriber. A record in subscriber worklist 423 is updated when a change occurs to the object data, when the change is processed (i.e., reconstructed and transmitted), and after that change has been made available to a subscriber. Fig. Figure 6 shows the subscriber worklist 423 according to some embodiments. The key field values of the subscriber worklist 423 specify a client, a timestamp, a subscriber ID, an object name, and an object type. In response to a request from a subscriber, the data reconstruction and data transfer process 421 can determine (via the status field of the subscriber worklist 423) whether updates to a particular object are available to the subscriber by querying the subscriber worklist 423 for the values of the appropriate key fields. The timestamp of a record can indicate a point in time when the record was last modified and can be used for error handling, as described below.
[0035] To log changes to database tables (including database tables underlying views), the change data capture engine 420 can create multiple database triggers (not shown) for each subscribed database table of the source system 410 to capture all update or delete operations on records in the database tables. In some embodiments, a database trigger creates a log entry associated with each detected operation and stores the log entry in a master log table (not shown) associated with the corresponding database table. An observer process (not shown) monitors the entries in the master log tables and copies entries corresponding to committed operations, in sequential order and with monotonically increasing sequence numbers, to log entries in the respective table-specific subscriber log tables 424.The data reconstruction and transfer process 421 can reconstruct object data changes based on the entries in the subscriber logging tables 424.
[0036] Fig. Figure 7 shows a subscriber logging table 424 for storing log entries associated with a specific data table of the source system 410. As in Fig. As shown in Figure 7, a log entry of the sample subscriber log table 424 contains the key fields of a modified record of the specified data table (e.g., order ID and item ID), a sequence ID, a timestamp, an operation identifier (e.g., insert, update, or delete), and a user identifier.
[0037] As described above, the sequence ID is assigned by the observer process when the record (reflecting a committed operation) is inserted into the subscriber log table 424. Inserting a record into the subscriber log table 424 also triggers the creation of a corresponding record in the subscriber worklist 423 with the status "open". Sequence IDs are assigned in ascending order. Accordingly, the sequence IDs of each record in the subscriber log table 424 indicate the order in which each associated operation was committed to the database.
[0038] Each data record of the last processed pointers 425 in Fig. Item 8 specifies, for a given client, subscriber, object, and log table (since an object can be associated with more than one underlying data table), a pointer to a last successfully processed log table entry. Last processed pointers 425 can be used to determine an initial log table entry from which multiple subsections for processing are defined, as in Fig. Figure 3 shows that recently processed pointers 425 can also be used by a cleanup process to determine a lowest pointer (e.g., a sequence ID) that has been processed by all subscribers of a given log table, and to delete all entries in the log table that have sequence IDs equal to or less than the lowest processed pointer.
[0039] The main part 426 is called by the data reconstruction and transfer process 421 to define subsections of log table entries for a given subscriber-object combination to be processed in parallel. The definitions are determined based on a last-processed pointer, a maximum pointer, and a maximum number of records for the subscriber-object combination, as described above. The main part 426 stores the definitions in subsection information 427 and subsection boundaries 428. The subsection information 427 can provide subsection IDs and state handling data for the subscriber-object combination, as described in Fig. 9 shown.
[0040] Subsection boundaries 428 can define table entry boundaries for each subsection of each subscriber logging table of a subsection, as shown in Fig. Figure 10 shows that in some embodiments, a subsection can be defined to contain records from one or more subscriber log tables. The boundaries define the range of pointers covered by a subsection for each subscriber log table. By inserting data into subsection information 427 and subsection boundaries 428 once these are defined, other processes can begin reconstructing and transferring the data before all subsections are defined, which can improve the overall latency.
[0041] According to some embodiments, the main part 426 updates a Boolean indicator (IN_CALCULATION) in a record of the subscriber worklist 423 before subsections are defined according to the record. The value of this indicator, together with the availability of the exclusive lock set when the record is retrieved from the subscriber worklist 423, can be used to determine whether the main part 426 is currently calculating subsections. This determination facilitates recovery after interrupted calculations due to system failures.
[0042] The Commit API 430 can be called by a subscriber to indicate to the Engine 420 that the data associated with a particular subsection has been successfully transferred. Similarly, the Rollback API 432 can be called to indicate data transfer problems for a particular subsection. Calls to either API can include the subscriber type, subscriber ID, object type, object name, and subsection ID.
[0043] Fig. Figure 11 is a flowchart of process 1100 according to some embodiments. Process 1100 is described in terms of its components. Fig. 4 described, but the embodiments are not limited thereto. As can be seen from the following description, the process 1100 can be carried out by any of the multiple instances of the data reconstruction and transfer process 421.
[0044] Initially, a request for changed data of an object is received in S1105 from a subscriber. This request can be received via an API call from subscriber 450 to the read module 440. The request initiates a process that attempts to set an exclusive lock in S1110 on the subscriber worklist set associated with the object. This lock prevents a concurrent process from updating the status of the subscriber worklist set to "in progress" and initiating the calculation of subsections for the same object.
[0045] The worklist record is read in S1115. The process continues to S1116 if the lock in S1110 was successful and a worklist record matching the subscriber-object combination exists with the status "open". As mentioned above, a subscriber worklist record associated with an object can be created with the status "open" if a change occurs to the object's data.
[0046] In S1120, a parallelization mode and a maximum number of records per subsection are defined. It is assumed that the performance settings corresponding to the current subscriber-object combination specify the use of parallelization and a maximum number of records per subsection greater than 0. Otherwise, the sequential processing of entries in the subscriber log table would be performed as usual.
[0047] According to some embodiments, the data reconstruction and transfer process 421 in S1125 sets the status of the worklist entry to "under calculation" and then instructs the main part 426 to define corresponding subsections. Accordingly, the main part 426 determines the last processed entry in S1130, and the maximum number of entries in the corresponding log table(s) is determined. The last processed entry can be obtained from Table 425 as described above.
[0048] Main part 426 determines subsection IDs and boundaries of multiple subsections in S1135. As described above, the boundaries can be determined based on the last processed entry, the maximum entry, and the maximum number of records per subsection. In the case of a view object associated with more than one database table (and subscriber log table), main part 426 determines subsection IDs and boundaries for each corresponding subscriber log table in S1135.
[0049] Next, the main part 426 in S1140 sets the status of each subsection in the subsection information 427 to "open". It is important to note that previously defined subsections that were not successfully processed are not recalculated and remain as previously defined in the subsection information 427 and the subsection boundaries 428. Therefore, if the maximum number of records per subsection of the object, noted in the performance settings 422, has been changed by the subscriber in the meantime, the sizes of the previously defined subsections will reflect the previous maximum number of records.
[0050] The current process then requests data from a subsection in S1150. In this context, if the subscriber 450 initiates more than one process via API calls to the read device 440, with each process intended to process a subsection in parallel, all processes except the first cannot set the exclusive lock in S1110 and proceed to S1150 to request a subsection. To prevent concurrent processes from retrieving data from the same subsection, the main section 426 can set an exclusive lock when a process requests a subsection ID by calling a procedure that throws an exception when a process requests a subsection ID, even if no subsections are yet available (i.e., "open"), because the definition of subsections is still running in parallel.The data reader 440 can handle the exception by returning a corresponding code to the subscriber in S1165 to inform the subscriber of the current unavailability of subsections.
[0051] Once a subsection ID is returned to a process, a status associated with the subsection ID in subsection information 427 is set to "In Progress," and the status timestamp is updated in S1155. The ID is then passed to the reconstruction and data transfer process 421 to reconstruct the records associated with the subsection based on the subsection's key field values. The required subscriber log table entries are selected based on the subsection ID and the boundaries specified in subsection boundaries 428.
[0052] The data records are transferred to the subscriber along with the subsection ID. The subscriber can then use the subsection ID in an API call to commit or reset the data transfer as described below.
[0053] The processing of one or more subsections may fail. As described below, such an error can cause the status of the corresponding subscriber worklist record and the status of the failed subsection(s) to be set to "failed." If the worklist entry read in S1115 has a "failed" status, the worklist entry in S1170 is reset from "failed" to "open," and the status of all corresponding failed subsections in S1175 is also reset from "failed" to "open." The process then continues to S1120 and proceeds as described above. The foregoing addresses a situation where subsections already exist for the subscriber-object combination and supports the definition of new subsections for log table entries created since the last subsection definition.
[0054] Fig. Figure 12 is a flowchart of process 1200 for handling a commit API call according to some embodiments. For example, subscriber 450 can call the commit API 430 along with a subsection ID once the subscriber has successfully transferred the data associated with the subsection ID to a target system. Main part 426 receives the commit call and the subsection ID in S1210. In response, main part 426 sets the subsection status in subsection information 427 to "complete" in S1220.
[0055] The main part 426 then determines in S1230 whether one or more other subsections are in progress. If so, process 1200 terminates and processing of the one or more other subsections continues. If not, S1240 determines whether all subsections defined along with the current subsection have a "complete" status. If not, at least one subsection has a "failed" status, and the process proceeds to S1280 to set the status of the corresponding subscriber worklist entry to "failed." As mentioned above, on the next read of the worklist entry, the entry and all associated "failed" subsections can be set to "open."
[0056] Alternatively, the worklist entry is removed from subscriber worklist 423 if S1240 determines that all subsections defined along with the current subsection have a "complete" status. Next, the most recently processed pointers associated with each subscriber log table used to reconstruct the transferred data are updated in S1260 with a pointer to the maximum number of log table entries used in S1130 to compute the subsections. The processed log table entries are removed in S1270. According to some embodiments, S1230 through S1270 can be performed by one or more other cleanup processes instead of in response to a commit call as described above.
[0057] Fig. Figure 13 is a flowchart of process 1300 for handling a rollback API call according to some embodiments. For example, subscriber 450 can call the rollback API 432 along with a subsection ID as soon as the subscriber determines that the transfer of data to the target system has failed. Main section 426 receives the rollback call and the subsection ID in S1310 and sets the subsection status in subsection information 427 in S1320 to "failed".
[0058] The main part 426 then determines in S1330 whether one or more other subsections are in progress. If so, process 1300 terminates and processing of the one or more other subsections continues. If not, the flow proceeds to S1340 to set the status of the corresponding subscriber worklist entry to "failed." Again, S1330 and S1340 can be executed by one or more other cleanup processes, instead of in response to a rollback call as described above.
[0059] The compilation and processing of subsections may be interrupted due to unexpected system or database problems. As a result, the compilation of subsections may be incomplete, or a subsection may be displayed as "in progress" even if the subscriber is no longer processing the subsection.
[0060] In some implementations, a check is performed periodically (e.g., every ten minutes) to identify subscriber worklist records that have a status of "in calculation" but are not locked. Given the lock set in S1110, such a scenario indicates that the compilation of the relevant subsections has been interrupted. All such records are changed to a status of "open" to allow for future compilation of the subsections.
[0061] Furthermore, as described above, the status timestamp is updated with the current timestamp whenever the status of a subsection is updated. The status timestamp can therefore be checked to identify subsections that are incorrectly displayed as "in progress." According to some embodiments, a check is performed periodically (e.g., every ten minutes) to identify any subsection that has been in the "in progress" status for at least one hour and to reset the subsection's status to "open." This allows a new process to handle the subsection as described above.
[0062] Fig.Figure 14 is a block diagram of System 1400 according to some embodiments. System 1400 includes a Replication System 1410, which may comprise an implementation of Replication System 110 or Subscriber 450. Replication System 1410 may be decentralized from Source System 1420 and communicate with Source System 1420 via remote function calls as described herein. Source System 1420 may comprise an implementation of Source System 120 or 310, and Target System 1430 may comprise an implementation of Target System 130. According to some embodiments, Replication System 1410 may communicate concurrently with many Source Systems and Target Systems to perform the replication of objects as described herein. Each of Systems 1410, 1420, and 1430 may comprise a general computing device and execute program code using one or more processing units to perform any of the functions described herein.Each of the systems 1410, 1420 and 1430 may, according to some embodiments, include other elements not shown.
[0063] All data storage devices mentioned herein can be provided via combinations of magnetic storage devices (e.g., hard disk drives and flash memory), optical storage devices, read-only storage devices (ROM), etc., while volatile memory may include random access memory (RAM), storage class memory (SCM), or other rapidly accessible memory.
[0064] The preceding diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may have more or different components arranged differently. Other topologies may be used in conjunction with other embodiments. Furthermore, each component or device described herein may be implemented by any number of devices communicating with each other over any number of other public and / or private networks. Two or more such computing devices may be located remotely and communicate with each other over any known network(s) and / or a dedicated connection.Each component or device may comprise any number of hardware and / or software elements suitable for providing the functions described herein, as well as any other functions. For example, each computing device used in an implementation of a system according to some embodiments may include a processor for executing program code, such that the computing device is configured as described herein.
[0065] All systems and processes discussed herein can be embodied in program code stored on one or more non-transient, computer-readable media. Such media can include, for example, a hard disk, a DVD-ROM, a flash drive, a magnetic tape, and memory units with volatile random-access memory (RAM) or read-only memory (ROM). Implementations are therefore not limited to a specific combination of hardware and software.
[0066] The embodiments described herein serve solely for illustration. Experts will recognize that other embodiments can be realized with modifications and changes compared to the embodiments described above.