Parallel processing of changes in a distributed system

Abstract

Systems and methods include receiving a request from a subscriber for changed data of an object; determining a journal table associated with the object and including a plurality of journal table entries; determining, based on the object and the subscriber, a pointer to a last processed entry of the journal table; defining a plurality of sub-portions of journal table entries following the last processed entry; and using a first process to reconstruct and transmit first data associated with a first of the plurality of sub-portions to the subscriber; and in parallel with the first process, using a second process to reconstruct and transmit second data associated with a second of the plurality of sub-portions to the subscriber.

Description

TECHNICAL FIELD BACKGROUND

[0001] Conventional database systems store large amounts of data related to many aspects of a business. It is often necessary to mirror portions of data stored in one system (i.e., a source system) within one or more other systems (i.e., target systems). For example, it can be necessary to mirror a portion of data stored in a source system that is particularly well suited for data collection and storage within a target system that is particularly well suited for data analysis.

[0002] A replication server can be used to create and update target objects (e.g., tables or views) in a target system that mirror corresponding source objects in a source system. The replication server can utilize a change data capture mechanism that executes on the source system. The change data capture mechanism includes database triggers that execute on the source system that identify and record changes that occur to specified source objects. In operation, the replication server requests changed data from the change data capture mechanism, and the change data capture assembles the recorded changes and returns the assembled changes to the replication server. The replication server then applies the assembled changes to the corresponding target objects.

[0003] Conventionally, the change data capture mechanism assembles changes using a single process. Such sequential processing can be sufficient if latency requirements are relaxed or the number of changes for a given object is low. However, for objects that exhibit a high change rate and / or use cases that require short latency between source object changes and delivery of the changes to corresponding target objects, sequential processing can be insufficient.

[0004] There is a need for a system for improving performance of change assembly and delivery of changes to target systems. SUMMARY BRIEF DESCRIPTION OF DRAWINGS

[0005] Figure 1 is a replication architecture in accordance with some embodiments.

[0006] Figure 2 is a flow diagram of parallel processing of changes in accordance with some embodiments.

[0007] Figure 3 shows a sub-portion of a subscriber log record table entry in accordance with some embodiments.

[0008] Figure 4 is a block diagram of a subscriber system and a source system including a change data capture engine that implements parallel processing of changes in accordance with some embodiments.

[0009] Figure 5 is a tabular representation of performance settings in accordance with some embodiments.

[0010] Figure 6is a tabular representation of a subscriber worklist according to some embodiments.

[0011] Figure 7 is a tabular representation of a subscriber journal table according to some embodiments.

[0012] Figure 8 is a tabular representation of a last processed pointer table according to some embodiments.

[0013] Figure 9 is a tabular representation of a subpart information table according to some embodiments.

[0014] Figure 10 is a tabular representation of a subpart boundary table according to some embodiments.

[0015] Figure 11 is a flowchart of a process to assemble and transmit changes according to some embodiments.

[0016] Figure 12 is a flowchart of a process to commit processing of a subpart according to some embodiments.

[0017] Figure 13 is a flowchart of a process to rollback processing of a subpart according to some embodiments.

[0018] Figure 14 is a block diagram of a computing device including a replication architecture according to some embodiments. DETAILED DESCRIPTION

[0019] The following description is provided to enable any person skilled in the art to implement and use the described embodiments. Various modifications, however, will be readily apparent to those skilled in the art.

[0020] Some embodiments provide parallel processing of changes to records of objects of a source system. Such parallel processing includes parallel assembly of changes to records and transmitting the assembled changes to requesting subscribers. Generally, parallel processing is provided by dividing the changes to records for a given subscriber / object combination into subparts and processing each subpart in parallel. Mechanisms for tracking parallel processing of subparts to avoid conflicts, committing successful processing, and processing processing failures are also provided.

[0021] Figure 1 A system 100 according to some embodiments is shown. The system 100 includes a replication system 110 for replicating data from a source system 120 to a target system 130. While Figure 1 While one source system and one target system are shown, in some embodiments, the replication system 110 can replicate data from any number of source systems to any number of target systems.

[0022] In general, the replication system 110 can execute the replication server 112 to maintain copies of one or more objects (e.g., tables, views) of the source system 120 in the target system 130 based on the configuration data 114. The configuration data 114 can specify particular objects of particular source systems to replicate for particular subscribers in one or more particular target systems. Maintaining such copies includes replicating records of the specified data tables in the data tables 127 to the data tables 134.

[0023] The client device system 140 can execute a client application 145 to communicate with the source system 120. According to some embodiments, the client application 145 can include code executed within a web browser executed by the client system 140. The client application 145 can include a business application that accesses data of the data tables 127. Such access can include inserting new records, updating existing records, or deleting existing records of the data tables 127. The client application 145 can also or instead provide a data archival function to move selected records of the data tables 127 to an archival data store (not shown).

[0024] The source system 120 can execute a replication source client 121 to record changes to objects specified in the configuration data 114 in the journaling tables 124. According to some embodiments, the replication source client 121 includes database triggers to detect insert, update, and delete operations performed on records of specified data tables in the data tables 127 during database transactions. In some embodiments, a separate database trigger is created for each operation on each specified table. The database triggers record the detected operations as log entries in corresponding journaling tables 124. In the case of objects that are data tables, the object is associated with only one journaling table 124. If the object is a view that selects data from more than one underlying data table, the object is associated with one journaling table for each underlying data table 124.

[0025] As will be described in detail below, for each database record affected by a database transaction, the journaling tables 124 can include a log entry that specifies a key field value of the database record and a type of operation performed on the record. The replication source client 121 can also include an observer process that reads the log entries and writes similar log entries to subscriber journaling tables, each associated with a particular data table. Based on requests received from subscribers (e.g., the replication server 112) for changed data of a given object, a data reconstruction and transfer process of the replication source client 121 reconstructs the changed data based on the log entries and transfers the changed data to the subscribers for subsequent transfer to the target systems. As noted above, two or more data reconstruction and transfer processes can proceed in parallel to reconstruct and transfer the changed data.

[0026] In particular, the processed pointer 125 indicates for a given subscriber and object one or more subscriber log record tables and for each of the one or more subscriber log record tables indicates the last subscriber log record table entry processed by the given subscriber. Also known are the current maximum pointers (i.e., the pointers to the current last entries) for each of the one or more subscriber log record tables. Based on the processed pointer 125 and the current maximum pointers, a "primary" portion of log record table entries is determined for each of the one or more subscriber log record tables. The primary portion consists of all entries following the last processed subscriber log record table entry up to and including the current last entry.

[0027] To enable parallel processing of the primary portion of log record table entries, each primary portion is divided into two or more sub-portions of log record table entries. The size of each sub-portion can be determined based on settings corresponding to the subscriber / object combination. The division of the primary portion into two or more sub-portions is described in detail below according to some embodiments.

[0028] The portion information 126 stores the state and boundaries (e.g., pointers to the first and last entries) of each sub-portion. In operation, the data reconstruction and transfer process uses the portion information 126 to reconstruct and transfer data associated with each sub-portion in parallel, as described below.

[0029] The data stored within the tables 127 and 134 can include one or more of regular tabular data, row-based data, column-based data, and object-based data. According to some embodiments, the replication server 112 operates to perform any transformations needed to convert the data from the format of the tables 127 to the format of the tables 134. The data can be distributed among several relational databases, dimensional databases, and / or other data sources.

[0030] Each of the source system 120 and the target system 130 can include any computing system capable of executing a database management system, storing and independently managing data for one or more tenants, and in some embodiments, supporting the execution of a database server application. As known in the art, each of the source system 120 and the target system 130 can include a distributed storage system and / or distributed server nodes for performing computing operations. According to some embodiments, the source system 120 is an on-premise transactional database system and the target system 130 is an in-memory database system configured to provide data analytics, although embodiments are not limited thereto. In this regard, a client application (not shown) can communicate with one or more server applications (not shown) executing on the target system 130 to perform data analytics on data stored in the tables 134.

[0031] Source system 120 and target system 130 can implement an in-memory database, in which a complete database is stored in volatile (e.g., non-disk-based) memory (e.g., random access memory). The complete database can be saved in a fixed disk (not shown) and / or backed up to a fixed disk. Embodiments are not limited to in-memory implementations. For example, source system 120 and target system 130 can store data in random access memory (e.g., cache memory for storing recently used data) and one or more fixed disks (e.g., persistent storage for storing respective portions of a complete database).

[0032] Figure 2 A process 200 of replicating data changes in parallel is shown, in accordance with some embodiments. Process 200 can be performed by replication source client 121 of FIG. 1, but embodiments are not limited to this. Figure 1

[0033] Process 200 and other processes described herein can be performed using any suitable combination of hardware and software. Software program code embodying these processes can be stored by any non-transitory tangible medium, including a fixed disk, volatile or non-volatile random access memory, a DVD, a flash drive, or a 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 virtual machines provided in a cloud-based architecture. Embodiments are not limited to the examples described below.

[0034] According to some embodiments, a request for changed data of an object is received from a subscriber at S210. It will be assumed that the changed data of the object exists and the flow proceeds to S220 as a result. Determination of whether the changed data exists will be described below, according to some embodiments.

[0035] At S220, a log record table entry associated with the subscriber and the object is determined based on one or more pointers to last processed log record table entries. In one example of S220, a subscriber log record table associated with the object is determined. If the object is a data table, the object is associated with only one subscriber log record table, and if the object is a view that selects data from more than one underlying data table, the object is associated with more than one subscriber log record table.

[0036] ​According to some embodiments of S220, the data structure (e.g., processed pointers 125) indicating the pointers to the last processed log record table entry for the subscriber, object, and combination of subscriber, object, and log record table determines the last processed pointer for each determined subscriber log record table. A current maximum pointer (i.e., a pointer to the current last entry) for each of the one or more subscriber log record tables is also determined. Then, at S220, log record table entries are determined for each of the one or more subscriber log record tables based on the last processed pointer and the current maximum pointer. The determined entries consist of all entries following the last processed subscriber log record table entry up to and including the current last entry.

[0037] Next, at S230, a plurality of sub-portions of the determined log record table entries are defined. The size of each sub-portion can be determined based on a maximum number of entries per sub-portion specified for the subscriber / object combination. The definition of the sub-portions can specify the corresponding subscriber log record table, state, and pointers to the first and last entries of the sub-portion.

[0038] Figure 3 The determination of log record table entries and the definition of sub-portions at S220 and S230 according to some embodiments is illustrated. As shown, the range of log record table entries 300 is determined based on the last processed pointer and the current (i.e., at S220) maximum pointer. The range is divided into sub-portions 1-4 according to the maximum number of records pre-specified for each portion of a given object and subscriber. Unless the records of the range are divisible by the specified maximum number of records, the last sub-portion (i.e., sub-portion 4) will include fewer entries than the maximum number of records specified for each portion. S230 includes storing the pointers to the first and last entries of the associated sub-portion in association with an identifier of each sub-portion 1-4.

[0039] During S220 and S230, the source system will continue to perform database transactions, which can result in the addition of log record table entries and the corresponding increase of the maximum pointer, as shown. Figure 3 These added log record table entries (i.e., located between the old maximum pointer and the current maximum pointer) are ignored during S230 and will be processed in the next processing run.

[0040] At S240, the determined log record table entries for each sub-portion are used to assemble data records corresponding to the changes of data for each sub-portion, and the data records are transmitted to the subscriber together with the sub-portion ID, as known in the art. The assembly and transmission of data records associated with one sub-portion can occur in parallel with the assembly and transmission of data records associated with at least one other sub-portion.

[0041] If the subscriber successfully transmits the data records associated with the subpart to the target system, a call to a commit API including the subpart ID can be received from the subscriber. In response, the status of the subpart is set to complete at S250. If the data transmission to the target system is unsuccessful, the subscriber can call a rollback API with the subpart ID. The rollback API sets the status of the subpart to failed at S260.

[0042] As will be described below, once a subpart is set to a complete status, various cleanup mechanisms can participate in updating the last processed pointer of the log record table and deleting the log record table entry for the subpart. Other error handling mechanisms (e.g., for handling failed subparts or errors during a subpart limit period) are also described below.

[0043] Figure 4 A system 400 according to some embodiments is shown. The system 400 can include an implementation of the system 100, although embodiments are not limited in this regard. Thus, embodiments of the system 400 can perform the process 200.

[0044] The system 400 includes a source system 410 and a subscriber system 450. The source system 410 includes a change data capture engine 420, which in turn includes a data reconstruction and transmission process 421. The data reconstruction and transmission process 421 orchestrates the selection of changes to records according to respective object types and initiates the reconstruction of data. For database tables, the data reconstruction and transmission process 421 returns complete records based on key field values of the records. For views, the data reconstruction and transmission process 421 returns results of the view itself based on key field values of the records, taking into account the various join conditions and computations of the view. After reconstruction, the data reconstruction and transmission process 421 transmits the reconstructed results to the object subscriber requesting the transmission.

[0045] As described above, the data reconstruction and transmission process 421 can operate on several subparts of key field values of records in parallel. A performance setting 422 defines whether log record table entries for a particular object-subscriber combination are processed in parallel. In general, the parallelization setting can be determined with a goal of maintaining a small number of records in the respective subscriber log record table, which indicates the most recent target system. For example, small objects and / or objects with low data velocity can be associated with sequential processing, while objects that experience many changes in a short period of time can be associated with parallel processing.

[0046] The performance settings 422 also specify a maximum number of records for each subpart. In the case of sequential processing, the specified maximum number of records can limit the maximum number of log record table entries that the sequential process is to process at a 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 a given time. Thus, the maximum number can be determined based at least in part on the size of each record of the object. Thus, the maximum number associated with a table having many fields can be lower than the maximum number associated with a table having fewer fields.

[0047] Figure 5 The performance settings 422 are shown in accordance with some embodiments. Each record of the performance settings 422 specifies a maximum number of records and a parallelization mode for each subpart for a particular combination of client (to account for multi-tenant source systems), subscriber ID, object name, and object type. The parallelization mode can indicate sequential processing or any of one or more parallelization types provided by the process 421.

[0048] The subscriber worklist 423 can indicate that, for a given subscriber and object, the object has been updated since the subscriber last received object data. The records of the subscriber worklist 423 are updated when object data is changed, when that change is being processed (i.e., rebuilt and transferred), and after the change is provided to the subscriber. Figure 6 The subscriber worklist 423 is shown in accordance with some embodiments. The key field values of the subscriber worklist 423 specify the client, timestamp, subscriber ID, and object name and object type. In response to a query from a subscriber, the data rebuild and transfer process 421 can determine whether an update to a particular object is available to the subscriber (via the status field of the subscriber worklist 423) by querying the subscriber worklist 423 with the values of the corresponding key fields. The timestamp of a record can indicate the time at which the record was last changed, and can be used for error handling as described below.

[0049] To record changes to database tables (including database tables underlying views), the change data capture engine 420 can create a plurality of database triggers (not shown) for each subscribed database table of the source system 410 to capture any update or delete operations to records of the database tables. In some embodiments, the database triggers create log entries associated with each detected operation and save the log entries in a master log record table (not shown) associated with the corresponding database table. An observer process (not shown) monitors the entries of the master log record table and copies the entries corresponding to committed operations in chronological order and with monotonically increasing sequence numbers into log entries of a corresponding table-specific subscriber log record table 424. The data rebuild and transfer process 421 can rebuild object data changes based on the entries of the subscriber log record table 424.

[0050] Figure 7 A subscriber log record table 424 is shown for storing log entries associated with a particular data table of the source system 410. As shown, a log entry of the example subscriber log record table 424 includes a key field of the changed data record of the particular data table (e.g., order ID and item ID), a sequence ID, a timestamp, an operation identifier (e.g., insert, update, or delete), and an identifier of the user. Figure 7

[0051] As described above, a sequence ID is assigned by the observer process when a record (reflecting a committed operation) is inserted into the subscriber log record table 424. Inserting a record into the subscriber log record table 424 also triggers the creation of a corresponding record in the subscriber work list 423 having a status "open." Sequence IDs are assigned in an increasing sequence. Thus, the sequence ID of each record of the subscriber log record table 424 indicates the order in which each associated operation was committed to the database.

[0052] Figure 8 Each record of the last processed pointer 425 specifies, for a given client, subscriber, object, and log record table (as an object can be associated with more than one underlying data table), a pointer to the last successfully processed log record table entry. The last processed pointer 425 can be used to determine an initial log record table entry from which to define a plurality of subparts for processing, as shown. Figure 3 The last processed pointer 425 can also be used by the cleanup process to determine the lowest pointer (e.g., sequence ID) pointing to a given log record table that was processed by all subscribers, and to delete all entries in the log record table having a sequence ID equal to or less than the lowest processed pointer.

[0053] The main part 426 is invoked by the data rebuild and transfer process 421 to define subparts of log record table entries to be processed in parallel for a given subscriber-object combination. As described above, the definition is determined based on the last processed pointer, the maximum pointer, and the maximum number of records for the subscriber-object combination. The main part 426 stores the definition in the subpart information 427 and the subpart boundaries 428. The subpart information 427 can provide a subpart ID and status processing data for the subpart for the subscriber-object combination, as shown. Figure 9

[0054] The subpart boundaries 428 can specify, for each subpart of each subscriber log record table of the subpart, a log record table entry boundary, as shown. Figure 10 ​​The subparts can be defined in some embodiments to include records from one or more subscriber log record tables. The boundaries specify the range of pointers covered by each subscriber log record table subpart. By inserting data into the subpart information 427 and the subpart boundaries 428 as it is determined, other processes can begin to reconstruct and transfer data before all subparts are defined, which can improve overall latency.

[0055] According to some embodiments, the main part 426 updates a Boolean indicator (IN_CALCULATION) in the record of the subscriber work list 423 before defining a subpart corresponding to the record. The value of this indicator, along with the availability of an exclusive lock set when the record is fetched from the subscriber work list 423, can be used to determine whether the main part 426 is currently calculating a subpart. This determination helps to recover from a calculation interrupted due to a system power interruption.

[0056] A commit API 430 can be called by a subscriber to indicate to the engine 420 that data associated with a given subpart was successfully transferred. Similarly, a rollback API 432 can be called to indicate that data transfer for a particular subpart was problematic. A call to either API can include the subscriber type, the subscriber ID, the object type, the object name, and the subpart ID.

[0057] Figure 11 is a flowchart of a process 1100 according to some embodiments. The process 1100 will be described with respect to the components of Figure 4 but embodiments are not limited thereto. As will be apparent from the description below, the process 1100 can be performed by each of the multiple instances of the data reconstruction and transfer process 421.

[0058] First, at S1105, a request for data of a change to an object is received from a subscriber. The request can be received through an API call to the reader module 440 from a subscriber 450. The request initiates a process that attempts to set an exclusive lock for the subscriber work list record associated with the object at S1110. The lock prevents concurrent processes from updating the state of the subscriber work list record to "in process" and starting a calculation on a subpart of the same object.

[0059] The work list record is read at S1115. If the lock was successful in S1110, the flow proceeds to S1116, and the work list record corresponding to the subscriber-object combination exists and has an "open" state. As described above, a record of the subscriber work list associated with an object can be created with an "open" state when data of the object is changed.

[0060] The parallelization mode and the maximum number of records per subpart are determined at S1120. It will be assumed that the performance settings corresponding to the current subscriber-object combination indicate the use of parallelization and that the maximum number of records per subpart is greater than 0. Otherwise, the sequential processing of the subscriber log record table entries will be performed in a known manner.

[0061] According to some embodiments, the data reconstruction and transfer process 421 sets the worklist record status to "in computation" at S1125, and then instructs the main part 426 to define the corresponding subparts. Thus, at S1130, the main part 426 determines the last processed entry and the maximum entry of the corresponding log record table(s) are determined. As mentioned above, the last processed entry can be determined from the table 425.

[0062] At S1135, the main part 426 determines the subpart ID and the boundaries of the plurality of subparts. As mentioned above, the boundaries can be determined based on the last processed entry, the maximum entry and the maximum number of records per subpart. In case the view object is associated with more than one database table (and subscriber log record table), the main part 426 determines at S1135 the subpart id and the boundaries of each corresponding subscriber log record table.

[0063] Next, at S1140, the main part 426 sets the status of each subpart to "open" in the subpart information 427. It should be noted that any previously defined subpart that was not successfully processed is not re-computed and remains as previously defined in the subpart information 427 and the subpart boundaries 428. Thus, if the maximum number of records per subpart of the object noted in the performance settings 422 has been changed by the subscriber during this time, the size of the previously defined subpart will reflect the previous maximum number of records.

[0064] The current process then requests the data of the subpart at S1150. In this regard, in case the subscriber 450 initiates more than one process by API calls to the reader 440, where each process is intended to process a subpart in parallel, then all processes except the first one will not be able to set the exclusive lock at S1110, and proceed to S1150 to request the subpart. In order to prevent concurrent processes from acquiring the data of the same subpart, the main part 426 can set an exclusive lock when a process is requesting a subpart ID by calling a method that raises an exception if the process is requesting the subpart ID, although no subpart is available (i.e. "open") yet, as the definition of the subpart is still running in parallel. The data reader 440 can handle the exception by returning a corresponding code to the subscriber at S1165 to inform the subscriber about the current unavailability of the subpart.

[0065] Once the subpart ID is returned to the process, the status associated with the subpart ID in the subpart information 427 is set to "in process" and the status timestamp is updated at S 1155. The ID is then passed to the rebuild and data transfer process 421 to rebuild the data record associated with the subpart based on the key field values of the subpart. The required subscriber journal table records are selected based on the subpart ID and the boundaries specified in the subpart boundaries 428.

[0066] The data record is transferred to the subscriber along with the subpart ID. The subscriber can then use the subpart ID in an API call to commit or roll back the data transfer as described below.

[0067] The processing of one or more subparts can fail. As will be described below, such a failure results in setting the status of the corresponding subscriber worklist record and the status of the failing subpart(s) to "failed". Thus, if the worklist record read at S 1115 has a status of "failed", the worklist record is reset from "failed" to "open" at S 1170 and the status of all corresponding failed subparts is reset from "failed" to "open" at S 1175. Flow then proceeds to S 1120 and continues as described above. The above handles the case where some subparts already exist for the subscriber-object combination and supports defining new subparts for journal table entries created since the last defined subpart.

[0068] Figure 12 is a flowchart of a process 1200 to handle a commit API call according to some embodiments. For example, once the subscriber successfully transfers the data associated with a subpart ID to the target system, the subscriber 450 can invoke the commit API 430 along with the subpart ID. The master portion 426 receives the commit call and the subpart ID at S 1210. In response, the master portion 426 sets the status of the subpart to "complete" in the subpart information 427 at S 1220.

[0069] Then, at S 1230, the master portion 426 determines whether one or more other subparts are in process. If so, the process 1200 terminates and the processing of the one or more other subparts continues. If not, a determination is made at S 1240 whether all subparts defined with the current subpart have a status of "complete". If not, at least one subpart has a status of "failed" and flow proceeds to S 1280 to set the status of the corresponding subscriber worklist record to "failed". As described above, the record and all associated "failed" subparts can be set to "open" on the next read of the worklist record.

[0070] Alternatively, if it is determined at S 1240 that all of the subparts defined with the current subpart have a "complete" status, the worklist record is removed from the subscriber worklist 423. Next, the last processed pointer associated with each subscriber journal table used to reconstruct the data delivered is updated at S 1260 with the pointer to the maximum journal table entry used to compute the subpart at S 1130. The processed journal table entries are removed at S 1270. According to some embodiments, S 1230 through S 1270 can be performed by one or more other cleanup processes rather than in response to a commit call as described above.

[0071] Figure 13 FIG. 13 is a flowchart of a process 1300 to handle a rollback API call according to some embodiments. For example, once a subscriber determines that a data delivery to a target system has failed, the subscriber 450 can call the rollback API 432 with the subpart ID. The master 426 receives the rollback call and the subpart ID at S 1310 and sets the status of the subpart to "failed" in the subpart information 427 at S 1320.

[0072] Then, at S 1330, the master 426 determines whether one or more other subparts are in processing. If so, the process 1300 terminates and processing of the one or more other subparts continues. If not, flow proceeds to S 1340 to set the status of the corresponding subscriber worklist record to "failed." Again, S 1330 and S 1340 can be performed by one or more other cleanup processes rather than in response to a rollback call as described above.

[0073] Assembly and processing of a subpart can be interrupted due to unexpected system or database problems. Thus, although the subscriber is no longer processing the subpart, the assembly of the subpart can not be complete or the subpart can be indicated as "in processing," even though the subscriber is no longer processing the subpart.

[0074] According to some embodiments, a check is run periodically (e.g., every ten minutes) to identify subscriber worklist records having a "computing" status but no lock exists. Such a condition indicates that assembly of the corresponding subpart was interrupted, given that a lock was placed at S 1110. Any such record is changed to an "open" status to allow future assembly of the subpart.

[0075] Further, as described above, when the status of a subpart is updated, the status timestamp is updated to the current timestamp. The status timestamp can thus be checked to identify subparts that are incorrectly indicated as "in processing." According to some embodiments, a check is run periodically (e.g., every ten minutes) to identify each subpart that has been in a "processing" status for at least one hour and reset the status of the subpart to "open." As a result, the subpart will be allowed to be processed by a new process, as described above.

[0076] Figure 14 is a block diagram of a system 1400 according to some embodiments. The system 1400 includes a replication system 1410, which can include an implementation of the replication system 110 or the subscriber 450. The replication system 1410 can be distributed from and communicate with a source system 1420 via remote function calls, as described herein. The source system 1420 can include an implementation of the source system 120 or 310, and a target system 1430 can include an implementation of the target system 130. According to some embodiments, the replication system 1410 can simultaneously communicate with many source systems and target systems to perform replication of objects, as described herein. Each of the systems 1410, 1420, and 1430 can include a general purpose computing device and can use a processing unit(s) to execute program code to perform any of the functions described herein. According to some embodiments, each of the systems 1410, 1420, and 1430 can include other elements not shown.

[0077] All data storage mentioned herein can be provided by a combination of magnetic storage devices (e.g., hard disk drives and flash memory), optical storage devices, read-only memory (ROM) devices, and the like, while volatile memory can include random access memory (RAM), storage class memory (SCM), or any other fast access memory.

[0078] The foregoing figures represent logical architectures used to describe processes according to some embodiments, and actual implementations can include more or different components arranged in other ways. Other topologies can be used in conjunction with other embodiments. Moreover, each component or device described herein can be implemented by any number of devices that communicate via any number of other public and / or private networks. Two or more such computing devices can be remote from each other and can communicate with each other via any known network manner and / or a dedicated connection. Each component or device can include any number of hardware and / or software elements suitable to provide the functionality described herein, as well as any other functionality. For example, any computing device used in an implementation of a system according to some embodiments can include a processor for executing program code such that the computing device operates in the manner described herein.

[0079] All systems and processes discussed herein can be embodied in program code stored on one or more non-transitory computer-readable media. Such media can include, for example, hard disks, DVD-ROMs, flash drives, magnetic tape, and solid-state random access memory (RAM) or read-only memory (ROM) storage units. Embodiments are therefore not limited to any specific combination of hardware and software.

[0080] The embodiments described herein are for illustrative purposes only. Those skilled in the art will recognize other embodiments that can be practiced by modification and variation of the above described embodiments.

Claims

1. A system comprising: a memory storing processor-executable process steps; a processing unit executing the processor-executable process steps to cause the system to: receive a request from a subscriber for changed data of an object, wherein the object is a database table stored in a source system; determine a journal table associated with the object and comprising a plurality of journal table entries, wherein the object is associated with only one journal table; determine, based on the object and the subscriber, a pointer to a last processed entry of the journal table; determine, based on setting data associated with the object and the subscriber included in the source system, to process the plurality of journal table entries in parallel; determine a current maximum journal table entry and a maximum number of records per subpart associated with the object and the subscriber; specify, based on the setting data, a maximum number of records per subpart for the object and the subscriber; determine a range of the plurality of journal table entries based on the pointer to the last processed entry and the current maximum journal table entry; divide the range into a plurality of subparts of journal table entries following the last processed entry according to the maximum number of records per subpart, wherein a size of each subpart is determined based on the maximum number of records per subpart; reconstruct and transmit, using a first process, first data associated with a first of the plurality of subparts to the subscriber; and reconstruct and transmit, using a second process, second data associated with a second of the plurality of subparts to the subscriber, wherein the first process and the second process operate in parallel.

2. The system of claim 1, the processor-executable process steps further causing the system to: receive a request from the subscriber for changed data of a second object; determine a second journal table associated with the second object and comprising a second plurality of journal table entries; determine, based on setting data associated with the second object and the subscriber, to process the second plurality of journal table entries sequentially; determine, based on the second object and the subscriber, a pointer to a last processed entry of the second journal table; and reconstruct second data associated with entries of the second plurality of journal table entries following the last processed entry; and transmit the second data to the subscriber.

3. The system of claim 1, the processor-executable process steps further causing the system to: determine that data of the object has changed; and in response to determining that data of the object has changed, create a record of a subscriber worklist associating the subscriber with the object, the first process setting a processing-in-progress state of the record of the subscriber worklist, limiting the plurality of subparts of journal table entries following the last processed entry, and setting an open state of the record of the subscriber worklist after limiting the subparts. wherein, ​ 4. The system according to claim 1, wherein, The first process sets an in-process state of a record of the subscriber work list, defines a plurality of sub-portions of the log record table entries after a last processed entry and sets an open state of the record of the subscriber work list after defining the sub-portions.

5. A computer-implemented method comprising: receiving a request from a subscriber for changed data of an object, wherein the object is a database table stored in a source system; determining a log record table associated with the object and comprising a plurality of log record table entries, wherein the object is associated with only one log record table; determining a pointer to a last processed entry of the log record table based on the object and the subscriber; determining to process the plurality of log record table entries in parallel based on setting data associated with the object and the subscriber included in the source system; determining a current maximum log record table entry and a maximum number of records per sub-portion associated with the object and the subscriber; specifying a maximum number of records per sub-portion for the object and the subscriber based on the setting data; determining a range of the plurality of log record table entries based on the pointer to the last processed entry and the current maximum log record table entry; dividing the range into a plurality of sub-portions of log record table entries after the last processed entry according to the maximum number of records per sub-portion, wherein a size of each sub-portion is determined based on the maximum number of records per sub-portion; reconstructing and delivering first data associated with a first of the plurality of sub-portions to the subscriber using a first process; and reconstructing and delivering second data associated with a second of the plurality of sub-portions to the subscriber using a second process in parallel with the first process.

6. The method of claim 5, further comprising: receiving a request from the subscriber for changed data of a second object; determining a second log record table associated with the second object and comprising a second plurality of log record table entries; determining to process the second plurality of log record table entries sequentially based on setting data associated with the second object and the subscriber; determining a pointer to a last processed entry of the second log record table based on the second object and the subscriber; and reconstructing second data associated with entries of the second plurality of log record table entries after the last processed entry; and delivering the second data to the subscriber.

7. The method of claim 5, further comprising: determining that data of the object has changed; and in response to determining that data of the object has changed, creating a record of a subscriber work list associating the subscriber with the object, wherein the first process sets an in-process state of the record of the subscriber work list, defines a plurality of sub-portions of the log record table entries after the last processed entry and sets an open state of the record of the subscriber work list after defining the sub-portions.

8. The method according to claim 5, wherein, The first process sets an in-process state of the record of the subscriber work list, defines a plurality of sub-portions of the log record table entries after the last processed entry and sets an open state of the record of the subscriber work list after defining the sub-portions.

9. A system comprising: a subscriber system; a source system storing a database table, the source system: receiving a request from a subscriber for changed data of a database table; determining a log record table associated with the database table and comprising a plurality of log record table entries, wherein the database table is associated with only one log record table; determining a pointer to a last processed entry of the log record table based on the database table and the subscriber; determining to process the plurality of log record table entries in parallel based on setting data associated with the object and the subscriber included in the source system; determining a current maximum log record table entry and a maximum number of records per sub-portion associated with the object and the subscriber; specifying a maximum number of records per sub-portion for the object and the subscriber based on the setting data; determining a range of the plurality of log record table entries based on the pointer to the last processed entry and the current maximum log record table entry; dividing the range into a plurality of sub-portions of log record table entries after the last processed entry according to the maximum number of records per sub-portion, wherein a size of each sub-portion is determined based on the maximum number of records per sub-portion; reconstructing and transmitting first data associated with a first of the plurality of sub-portions to the subscriber system using a first process; and reconstructing and transmitting second data associated with a second of the plurality of sub-portions to the subscriber system using a second process, wherein the first process and the second process operate in parallel.

10. The system of claim 9, the source system: receiving a request from the subscriber for changed data of a second database table; determining a second log record table associated with the second database table and comprising a second plurality of log record table entries; determining to process the second plurality of log record table entries sequentially based on setting data associated with the second database table and the subscriber; determining a pointer to a last processed entry of the second log record table based on the second object and the subscriber; and reconstructing second data associated with entries of the second plurality of log record table entries after the last processed entry; and transmitting the second data to the subscriber system.

11. The system of claim 9, the source system: determining that data of the database table has changed; and in response to determining that data of the database table has changed, creating a record of a subscriber work list associating the database table with the object, wherein, the first process sets an in-process state of the record of the subscriber work list, defines a plurality of sub-portions of the log record table entries after the last processed entry and sets an open state of the record of the subscriber work list after defining the sub-portions.

Images