| Class / Patent application number | Description | Number of patent applications / Date published |
|---|
| 707615000 | Transactional replication | 49 |
| 20100070471 | TRANSACTIONAL APPLICATION EVENTS - Techniques for processing transactional application events are described herein. In one embodiment, a database transaction record is retrieved from a database transaction log, where the database transaction record includes information of a database transaction and an application event associated with the database transaction. In response, a database operation specified in the database transaction is performed, where the database operation is configured to update one or more records of a database. The application event is extracted from the database transaction record retrieved from the database transaction log. An event operation associated with the application event that is associated with the database transaction is performed, such that when the event operation is performed, the updated one or more records of the database are readily available. Other methods and apparatuses are also described. | 03-18-2010 |
| 20100131466 | SYSTEM AND METHOD FOR SUPPORTING ASYNCHRONOUS DATA REPLICATION WITH VERY SHORT UPDATE INTERVALS - A system and method for improving the efficiency of the transmission of updated blocks generated by logging all the block allocations and deletes as well as CPs and PCPI creation and deletion in a persistent log. The log is scanned during each update cycle (in which changes are transmitted to a destination mirror) by the storage operating system, and only changed blocks that are referenced by the file system as it existed at the end of the update cycle or referenced by PCPIs that existed at the end of the update cycle are actually sent in the transmission. This reduces the number of changes being transmitted. | 05-27-2010 |
| 20100198785 | SELECTIVELY TRANSMITTING TRANSACTION DATA - A last transaction for a business object may be identified. Transactions related to that occur prior to the last transaction and subsequent to a last upload event are associated with the last transaction. Data describing the last transaction and the associated transactions may be transmitted over a communications network. Related apparatuses, techniques, systems, computer program products are also described. | 08-05-2010 |
| 20100332448 | METHOD FOR ENSURING REFERENTIAL INTEGRITY IN REPLICATION ENGINES BY RESOLVING LOCK CONFLICTS - A method is provided for processing base level data of a change queue that is not serialized at the logical level. The base level change queue data is transaction data previously posted to a source database. A logical replication engine is provided to replicate and post the change queue data to a target database in the order that the transaction data is stored in the change queue. Upon detection in the logical replication engine of change queue data that is not serialized at the logical level, the change queue data is reserialized at the logical level before the logical replication engine applies the change queue data to the target database. The change queue data that is not serialized at the logical level may be posted to the target database using asynchronous database access. | 12-30-2010 |
| 20100332449 | METHOD FOR ENSURING REPLICATION WHEN SYSTEM RESOURCES ARE LIMITED - A method is provided for replicating transaction data from a source database to a target database wherein the transaction data is communicated from a change queue associated with the source database to the target database. An initial path is provided between the change queue and the target database for transaction data to flow. The initial path has a maximum transaction load capacity. It is then detected whether the current transaction load is close or equal to the maximum transaction load capacity of the initial path. If so, another path is provided between the change queue and the target database. Also, a method is provided of replicating transaction data from a source database to a target database wherein an associated with the target database has a maximum transaction threshold limit. The applier normally posts transaction data to the target database only upon receipt of a commit step or operation associated with respective transaction data. First, it is detected as to whether the maximum transaction threshold limit of the applier has been reached. If so, a commit step or operation is prematurely conducted on at least some of the transaction data in the applier, thereby causing the transaction data to become posted to the target database and deleted from the applier. | 12-30-2010 |
| 20110016085 | METHOD AND SYSTEM FOR MAINTAINING MULTIPLE INODE CONTAINERS IN A STORAGE SERVER - A system and method for maintaining multiple inode containers is used to manage file system objects in a single logical volume of a network storage server. The system provides multiple inode containers to store metadata for file system objects in the logical volume. The system may use a first inode container to store private inodes used by the storage server and a second inode container to store public inodes that are useable by clients of the storage server. During a replication process, a source storage server generates a set of replication operations based on inodes in the public inode container and excluding inodes in the private inode container. In a destination server implementing multiple inode containers, the server generates inodes based on the replication operations and stores the inodes in the public inode container. These new inodes are stored in the public inode container with the same inode number or identifier as the corresponding inode on the source storage server. | 01-20-2011 |
| 20110035356 | TRANSACTIONAL ARCHIVING OF AN ELECTRONIC DOCUMENT - Various methods and apparatus are described for archiving of an electronic document between multiple interconnected archive units of a distributed server network in geographically-dispersed locations in order to store identical copies of the electronic document at the same time. An archival portal server in the distributed server network sends a five-step, two-phase commit protocol to a selected set of two or more transaction manager instances resident on remote archive units. The archival system reconciles if an error occurs between a start of a transmission of the electronic document and a permanent archiving of that electronic document, or the electronic document is stored in a permanent data storage location within each of the archive units at an end of the two-phase commit protocol making archiving of an electronic document to multiple locations an atomic operation. | 02-10-2011 |
| 20110066592 | Real Time Data Replication - A combination of synchronous and asynchronous replication of data is used to replicate a local database to a replicated database. The typical tradeoff between synchronous and asynchronous replication is optimized by using hybrid replication, which is to use synchronous replication for inserting new data and asynchronous replication for updating existing data. The combined use of synchronous and asynchronous in this manner provides an efficient replicated database where the replicated database can tolerate some delay in data updates but requires no data loss of new data. | 03-17-2011 |
| 20110082832 | PARALLELIZED BACKUP AND RESTORE PROCESS AND SYSTEM - A system and methods for parallelized backup and restore process and system are disclosed. In one embodiment, a method includes providing a massively parallelized analytic database, serializing a schedule of a transaction history of the massively parallelized analytic database, and creating a transactionally consistent copy of the massively parallelized analytic database. The method may include restoring one or more of an original system and a configurationally equivalent system to a transaction consistent state as of a time the transactionally consistent copy was created. The transactionally consistent copy may be stored on a separate system than the original system. Accessibility to the transactionally consistent copy may be retained on the separate system even when the original system is inaccessible by the storing of the transactionally consistent copy on the separate system. | 04-07-2011 |
| 20120101990 | METHOD FOR ENSURING REPLICATION FROM A CHANGE QUEUE OF A SOURCE DATABASE TO A TARGET DATABASE WHEN TRANSACTION LOAD EXCEEDS DATA PATH BY SPAWNING A NEW TRANSACTION PATH BETWEEN THE CHANGE QUEUE AND THE TARGET DATABASE - A method is provided for replicating transaction data from a source database to a target database wherein the transaction data is communicated from a change queue associated with the source database to the target database. An initial path is provided between the change queue and the target database for transaction data to flow. The initial path has a maximum transaction load capacity. It is then detected whether the current transaction load is close or equal to the maximum transaction load capacity of the initial path. If so, another path is provided between the change queue and the target database. | 04-26-2012 |
| 20120221519 | APPLICATION WORKLOAD CAPTURE AND REPLAY SYSTEM - An application workload capture and replay system with a transactionally consistent application workload replay feature is provided. More particularly, the feature includes capture-phase components for capturing and recording a real application workload submitted to a production web application system and includes replay-phase components for replaying the captured application workload against a test web application system in a transactionally consistent manner. The feature provides guarantees about the order of database transactions that are caused when the workload is replayed such that there is a consistency between the replay-phase order of the database transactions and the order of those transactions that occurred when the workload was captured. These consistency guarantees facilitate a faithful reproduction of database changes observed in the production web application system in the test web application system using a captured real application workload. Significantly, this faithful reproduction may be accomplished without having to create a synthetic application workload that approximates or emulates the transactional behavior of the real application workload. Instead, a real application workload may be used as or substantially as it is captured. | 08-30-2012 |
| 20120254105 | Synchronizing Records Between Databases - The described implementations relate to synchronizing records between databases. One implementation can cause historical data of a source database to be recorded as entries on a transaction log and can subsequently cause new data of the source database to be recorded on the transaction log in a same manner as the historical data. This implementation can also identify a distinct attribute associated with an individual entry and generate a message that reflects the individual entry. | 10-04-2012 |
| 20120284228 | User-Defined Parallelization in Transactional Replication of In-Memory Database - A replication track is a designated group of transactions that are to be replicated at a destination database in a way that, with respect to any other transaction in the replication track, preserves transactional dependency. Further, transactions in a replication track can be replicated at the destination database without regard to transactional dependency of other transactions in another track. This facilitates concurrent parallel replication of transactions of different tracks. Replicating data in this manner is referred to herein as track replication. An application may request execution of transactions and designate different tracks for transactions. | 11-08-2012 |
| 20120303578 | Versioned And Hierarchical Data Structures And Distributed Transactions - Presented herein are methods of replicating versioned and hierarchical data structures, as well as data structures representing complex transactions. Due to interdependencies between data entities and a lack of guaranteed message ordering, simple replication methods employed for simple data types cannot be used. Operations on data structures exhibit dependencies between the messages making up the operations. This strategy can be extended to various types of complex transactions by considering certain messages to depend on other messages or on the existence of other entries at the data store. Regardless of origin, these dependencies can be enforced by suspending the processing of messages with unsatisfied dependencies until all of its dependencies have been met. Alternately, transactions can be committed immediately, creating entities that include versioned identifiers for each of their dependencies. These entities can then be garbage collected of the parent objects are not subsequently created. | 11-29-2012 |
| 20120303579 | CONCURRENT CHECKPOINTING AND MODIFICATIONS IN A TRANSACTIONAL CLUSTERED FILE SYSTEM - Systems, Methods, and Computer Program Products are provided for concurrent checkpointing and modifications in a transactional clustered file system (CFS). Shadow data segments, whose contents are identical to an original data segment currently being written by a checkpoint operation, for users that require access for modification to data segments concurrently being written within a checkpoint operation. | 11-29-2012 |
| 20130036089 | SYSTEMS AND METHODS FOR ASYNCHRONOUS DISTRIBUTED DATABASE MANAGEMENT - Embodiments of the present disclosure include systems and methods for asynchronous distributed database management. In one embodiment, the systems and methods wait to execute or update a database transaction or command until specific conditions are satisfied, essentially divorcing the read-time from update-time in evaluation of a single expression. Accordingly, the systems and methods described herein can, in some instances, resolve the temporary inconsistencies without aborting and/or otherwise terminating a database transaction that would otherwise be aborted. | 02-07-2013 |
| 20130080386 | DATABASE CACHING UTILIZING ASYNCHRONOUS LOG-BASED REPLICATION - A database table within a database to persist within a cache as a cached table can be identified. The database can be a relational database management system (RDBMS) or an object oriented database management system (OODBMS). The cache can be a database cache. Database transactions within can be logged within a log table and the cached table within the cache can be flagged as not cached during runtime. An asynchronous replication of the database table to the cached table can be performed. The replication can execute the database transactions within the log table upon the cached table. The cached table can be flagged as cached when the replication is completed. | 03-28-2013 |
| 20130185255 | DATABASE MANAGEMENT METHOD - A lower-level master node sends, to a higher-level master node, a write set expanded in its own memory including a shadow copy of its own database and a heap tuple map, and the higher-level master node that received the write set verifies whether the update has already been executed and sends the record of this update to the lower-level master node as a transaction log, whereby the database can be updated efficiently and consistently from the lower-level master node to the higher-level master node, and from the higher-level master node to the lower-level master node under its control. | 07-18-2013 |
| 20130246352 | SYSTEM, METHOD, AND COMPUTER PROGRAM PRODUCT FOR GENERATING A FILE SIGNATURE BASED ON FILE CHARACTERISTICS - A system, method, and computer program product are provided for generating a file signature using file characteristics. In use, a plurality of characteristics of a file is identified. Furthermore, a signature for the file is generated based on a combination of the characteristics. | 09-19-2013 |
| 20130290251 | ASYNCHRONOUS DATA BINDING - The present invention extends to methods, systems, and computer program products for asynchronously binding data from a data source to a data target. A user interface thread and a separate thread are used to enable the user interface thread to continue execution rather than blocking to obtain updated data, to which elements of a user interface that the user interface thread is managing, are bound. The separate thread obtains updated data from a data source, stores the updated data in a local cache, and notifies the user interface thread of the updated data's presence in the local cache. The user interface thread, upon detecting the notification, accesses the updated data in the local cache and populates the updated data into the user interface | 10-31-2013 |
| 20140089260 | WORKLOAD TRANSITIONING IN AN IN-MEMORY DATA GRID - Embodiments of the present invention disclose a method, system, and computer program product for transitioning a workload of a grid client from a first grid server to a second grid server. A replication process is commenced transferring application state from the first grid server to the second grid server. Prior to completion of the replication process: the grid client is rerouted to communicate with the second grid server. The second grid server receives a request from the grid client. The second grid server determines whether one or more resources necessary to handle the request have been received from the first grid server. Responsive to determining that the one or more resources have not been received from the first grid server, the second grid server queries the first grid server for the one or more resources. The second grid server responds to the request from the grid client. | 03-27-2014 |
| 20140149346 | SYSTEM AND METHOD FOR MAINTAINING DISTRIBUTED DATA TRANSACTION ATOMICITY AND ISOLATION DURING A REPLICATION TO A DIFFERENT TARGET CLUSTER - A replicator system and method to maintain the ACID characteristics of a transaction upon an asynchronous replication from a cluster to a different cluster. | 05-29-2014 |
| 20140181017 | CONSISTENT REPLICATION OF TRANSACTIONAL UPDATES - Embodiments of the present invention provide a method, system and computer program product for consistent replication of transactional updates. In an embodiment of the invention, a method for consistent replication of data in a transaction processing system is provided. The method includes recording entries in a replication log of different data updates and corresponding transactions and additionally recording entries in the replication log indicating whether or not the transactions have been backed out. The method also includes replicating only those data updates referenced in the log which do not correspond to transactions indicated in the log to have been backed out. For instance the additionally recorded entries in the replication log indicate when a transaction has been backed out. Alternatively, the additionally recorded entries in the replication log indicate when a transaction has been committed. | 06-26-2014 |
| 20140181018 | CONSISTENT REPLICATION OF TRANSACTIONAL UPDATES - Embodiments of the present invention provide a method, system and computer program product for consistent replication of transactional updates. In an embodiment of the invention, a method for consistent replication of data in a transaction processing system is provided. The method includes recording entries in a replication log of different data updates and corresponding transactions and additionally recording entries in the replication log indicating whether or not the transactions have been backed out. The method also includes replicating only those data updates referenced in the log which do not correspond to transactions indicated in the log to have been backed out. For instance the additionally recorded entries in the replication log indicate when a transaction has been backed out. Alternatively, the additionally recorded entries in the replication log indicate when a transaction has been committed. | 06-26-2014 |
| 20140188795 | PROVIDING HIGH AVAILABILITY IN AN ACTIVE/ACTIVE APPLIANCE CLUSTER - A method routes data to an appliance in a high-availability active/active appliance cluster. Messages received by appliances are assigned by a self-balancing module to balance a load of appliances in the appliance cluster, which includes a persistent storing standby group and a transaction processing standby group. Persistent storing data, which is generated by processing the messages, are stored in a virtual persistent storage, which provides an interface between a persistent storage of a primary database appliance and an application for processing the messages. The virtual persistent storage is linked to the persistent storage of the primary database appliance in response to an appliance that receives the messages not being the primary database appliance, thereby sending persistent storing data to the persistent storage of the primary database appliance. | 07-03-2014 |
| 20140250061 | SYSTEM AND METHOD FOR ACCESSING INFORMATION IN A REPLICATED DATABASE - A method for accessing information in a replicated database may include receiving a request for information in a database. The request may be associated with a table in the database. The table may include a plurality of identifiers each identifying a portion of the information in the table. The method may also include executing a logical structure associated with the table to produce a logical view of the table. The logical view may contain at least a portion of the information from the table, without containing the identifiers. The method may further include identifying the requested information in the logical view, and communicating the identified requested information in the logical view. | 09-04-2014 |
| 20140258226 | ASYNCHRONOUS TRANSACTION MANAGEMENT, SYSTEMS AND METHODS - The invention discloses a system and method for simulating the asynchronous replication process. Transactions received by a server can be organized according to timestamp information or other metadata information, and are executed. The timestamp information can be modified to allow for time-shifted execution of the transactions, thereby compressing or extending the duration of the simulation. | 09-11-2014 |
| 20140310239 | Executing Distributed Globally-Ordered Transactional Workloads in Replicated State Machines - A method of transaction replication includes transmitting at least one transaction received during an epoch from a local node to remote nodes of a domain of 2N+1 nodes at the end of an epoch (N is an integer greater than or equal to 1). The remote nodes log receipt of the at least one transaction, notify the local node of the receipt of the at least one transaction, transmit the at least one transaction to all of the 2N+1 nodes, and add the at least one transaction to an execution order upon receiving at least N+1 copies of the at least one transaction. | 10-16-2014 |
| 20140310240 | EXECUTING DISTRIBUTED GLOBALLY-ORDERED TRANSACTIONAL WORKLOADS IN REPLICATED STATE MACHINES - A method of transaction replication includes transmitting at least one transaction received during an epoch from a local node to remote nodes of a domain of 2N+1 nodes at the end of an epoch (N is an integer greater than or equal to 1). The remote nodes log receipt of the at least one transaction, notify the local node of the receipt of the at least one transaction, transmit the at least one transaction to all of the 2N+1 nodes, and add the at least one transaction to an execution order upon receiving at least N+1 copies of the at least one transaction. | 10-16-2014 |
| 20150088820 | PERSISTENT DATA STORAGE TECHNIQUES - A database is maintained that stores data persistently. Tasks are accepted from task sources. At least some of the tasks have competing requirements for use of regions of the database. Each of the regions includes data that is all either locked or not locked for writing at a given time. Each of the regions is associated with an available processor. For each of the tasks, jobs are defined each of which requires write access to regions that are to be accessed by no more than one of the processors. Jobs are distributed for concurrent execution by the associated processors. | 03-26-2015 |
| 20150095280 | DATA SYNCHRONIZATION METHOD, DATA SYNCHRONIZATION APPARATUS, AND STORAGE MEDIUM FOR SYNCHRONIZING DATA AMONG A PLURALITY OF DATABASES - In a method for writing data having been subjected to transaction processing in a synchronization source database to data in a synchronization destination database, a synchronization processing management unit of the synchronization destination database requests, as synchronization target data, first data that is a part of the data having been subjected to the transaction processing from the synchronization source database, receives at least the first data from the synchronization source database, performs first synchronization processing on the first data in a cache memory, and performs second synchronization processing on second data, in the synchronization destination database, which has been processed in a same transaction as a transaction in which the first data has been processed in the synchronization source database. | 04-02-2015 |
| 20150112929 | Parallel Truncation Point Management for Log Based Replication - Disclosed herein are system, method, and computer program product embodiments for replicating data in a distributed database system. Data containing a replicated truncation point associated with a replicating system is received via a data path. It can then be determined that the truncation point represents the point at which all data in a transaction log has been replicated (e.g., successfully or safely) and the transaction log can then be truncated at the truncation point (i.e., the data up to the truncation point deflected). Data containing an additional replicated truncation point associated with an additional replicating system via an additional data path may be received. It can then be determined that the additional replicated truncation point represents the point at which all data in the transaction log has been replicated and the transaction log can be then truncated at the additional replicated truncation point. | 04-23-2015 |
| 20150317349 | PROVIDING EVENTUAL CONSISTENCY FOR MULTI-SHARD TRANSACTIONS - A multi-shard database system receives a transaction including multiple actions directed to different shards of the database system. The database system creates a transaction record including a transaction identifier and a transaction status for the transaction in a transaction database. The database system then executes, in parallel, the multiple actions on the different shards by associating with each data item involved in the transaction a data structure that includes the transaction identifier and new data to be applied to the data item. The database system then updates the transaction status in the transaction record for the transaction from pending to completed when each of the multiple actions is successfully executed on the corresponding shard. Consistency is eventually implemented when the data structures associated with the data items involved in the transaction are evaluated. The evaluation of a data structure can be triggered by a read request or other events. | 11-05-2015 |
| 20150347551 | APPLYING TRANSACTION LOG IN PARALLEL - System, method, computer program product embodiments and combinations and sub-combinations thereof for data replication in a database system environment are described. In an aspect, the data replication includes grouping, in-memory, a plurality of transactions to be replicated as a single transaction from a source database system to a target database system. A plurality of net row changes is compiled for the plurality of transactions, and data inconsistency detection and resolution within a command application order are performed. The plurality of net row changes are organized in segments and the segments can be applied simultaneously in bulk to the target database system. | 12-03-2015 |
| 20150379105 | TRANSACTION COMPLETION IN A SYNCHRONOUS REPLICATION ENVIRONMENT - Systems and methods are presented for completing transactions in a synchronous replication environment. In some embodiments, a computer-implemented method can include generating in a database server, an identifier to identify a database transaction. The method can also include transmitting the identifier to a replication server; receiving acknowledgement that the identifier is acknowledged by the replication server; storing the transaction in the database server; and executing the transaction after receiving acknowledgement from the replication server and after determining the transaction is stored in the database server; wherein transmitting the identifier to the replication server occurs in parallel with storing the transaction in the database server. | 12-31-2015 |
| 20160078116 | PROVIDING HIGH AVAILABILITY IN AN ACTIVE/ACTIVE APPLIANCE CLUSTER - A method executes a preempt by a standby database appliance in a high-availability active/active appliance cluster. The appliance cluster includes a transaction processing standby group and a persistent storing standby group. The transaction processing standby group includes a primary active appliance and a standby appliance. One or more processors receive a Hello message from the primary DB appliance. The processor(s) examine a priority field in the Hello message, in order to determine a priority of the standby database appliance according to the persistent state to thereby determine whether the standby database appliance requests a preempt, where the persistent state includes a state of an application and a database of the primary DB appliance. The processor(s) implement a failover in response to the preempt request to thereby take over a duty of the primary DB appliance. | 03-17-2016 |
| 20160085772 | AUTOMATED CONFIGURATION OF LOG-COORDINATED STORAGE GROUPS - A configuration manager of a storage service receives a set of service requirements, comprising one or more of: a performance requirement for one or more types of storage operations, or an access interface type requirement Based on the service requirements, a candidate storage configuration that includes one or more data store instances and a first log-based transaction manager is generated. Subsequent to an approval of the first storage configuration by a client, the establishment of the data store instances and the log-based transaction manager is initiated. | 03-24-2016 |
| 20160110408 | OPTIMIZED LOG STORAGE FOR ASYNCHRONOUS LOG UPDATES - A log-structured data store may implement optimized log storage for asynchronous log updates. In some embodiments, log records may be received indicating updates to data stored for a storage client and indicating positions in a log record sequence. The log records themselves may not be guaranteed to be received according to the log record sequence. Received log records may be stored in a hot log portion of a block-based storage device according to an order in which they are received. Log records in the hot log portion may then be identified to be moved to a cold log portion of the block-based storage device in order to complete a next portion of the log record sequence. Log records may be modified, such as compressed, or coalesced, before being stored together in a data block of the cold log portion according to the log record sequence. | 04-21-2016 |
| 20160125019 | APPARATUS AND METHOD FOR PROCESSING A QUERY - Apparatus and method for processing a query. The apparatus includes: a storage unit configured to store (i) a plurality of safe elements committed and saved in the database, and (ii) a plurality of unsafe elements for updating the plurality of safe elements, wherein the unsafe elements are not committed or committed, but not saved; a first query executing unit configured to execute the query on the plurality of unsafe elements; a second query executing unit configured to execute the query on the plurality of safe elements after the first query executing unit executes the query; and a third query executing unit configured to execute the query on at least one safe element saved during execution of the query by the second query executing unit after the second query executing unit executes the query. There is also provided another apparatus and a method. | 05-05-2016 |
| 20160125060 | ASYNCHRONOUS PROCESSING TIME METRICS - Asynchronous operations associated with a request such as threads, runnable elements, callable elements, and other invokable objects are tracked to determine the metrics about the request and operations. The present technology tracks the start and end of each asynchronous operation and maintains a counter which tracks the currently pending or executing asynchronous operations. By monitoring the request, the start and end of each asynchronous operation associated with the request, and the number of asynchronous operations currently executing, the present technology may identify the end of a request by identifying when the last asynchronous operation associated with the request ends. In some instances, the present technology identifies the end of a request when a counter which tracks the number of asynchronous operations executing reaches a value of zero after the first asynchronous operation has already begun. Tracking these operations allows the present technology to aggregate and report useful performance data about these requests. | 05-05-2016 |
| 20160132581 | Pipelining Paxos State Machines - Paxos transactions are pipelined in a distributed database formed by a plurality of replica servers. A leader server is selected by consensus of the replicas, and receives a lock on leadership for an epoch. The leader gets Paxos log numbers for the current epoch, which are greater than the numbers allocated in previous epochs. The leader receives database write requests, and assigns a Paxos number to each request. The leader constructs a proposed transaction for each request, which includes the assigned Paxos number and incorporates the request. The leader transmits the proposed transactions to the replicas. Two or more write requests that access distinct objects in the database can proceed simultaneously. The leader commits a proposed transaction to the database after receiving a plurality of confirmations for the proposed transaction from the replicas. After all the Paxos numbers have been assigned, inter-epoch tasks are performed before beginning a subsequent epoch. | 05-12-2016 |
| 20160140202 | ASYNCHRONOUS REPLICATION IN A DISTRIBUTED STORAGE ENVIRONMENT - Embodiments of the present invention relate to asynchronously replicating data in a distributed computing environment. To achieve asynchronous replication, data received at a primary data store may be annotated with information, such as an identifier of the data. The annotated data may then be communicated to a secondary data store, which may then write the data and annotated information to one or more logs for eventual replay and committal at the secondary data store. The primary data store may communicate an acknowledgment of success in committing the data at the primary data store as well as of success in writing the data to the secondary data store. Additional embodiments may include committing the data at the secondary data store in response to receiving an instruction that authorizes committal of data through an identifier. | 05-19-2016 |
| 20160147614 | Synchronized Backup and Recovery of Database Systems - Disclosed herein are system, method, and computer program product embodiments for utilizing a backup catalog to perform synchronized backup and recovery of heterogeneous database systems. An embodiment operates by performing a global data backup of a heterogeneous database system comprising a first database management system (DBMS) at a first server and a second DBMS at a second server and recording a global data backup entry identifying the global data backup into a backup catalog. Upon receiving log backup notifications regarding asynchronous log backups on the first server and the second server, log backup entries identifying the asynchronous log backups are recorded into the backup catalog. To successfully perform a point-in-time recovery, the embodiment operates by using the backup catalog to identify data and log backups required for the recovery of the first and second servers to a recovery timestamp associated with the point-in-time recovery. | 05-26-2016 |
| 20160147858 | Log Forwarding to Avoid Deadlocks During Parallel Log Replay in Asynchronous Table Replication - Disclosed herein are system, method, and computer program product embodiments for removing a deadlock during replication from distributed source tables to a replica node. An embodiment operates by detecting a deadlock at a parallel log replayer at a replica node. A first replication log entry from a queue at the parallel log replayer is then selected based on whether removing the first replication log entry from the queue removes the deadlock. The first replication log entry is then forwarded to a waiting queue. A second replication log entry is then replayed at the parallel log replayer. After replaying the second replication log entry, the first replication log entry is replayed at the parallel log replayer. | 05-26-2016 |
| 20160147859 | Transactional and Parallel Log Replay for Asynchronous Table Replication - Disclosed herein are system, method, and computer program product embodiments for replicating a database transaction to a replica table. An embodiment operates by receiving a replication log entry and an associated transaction commit log entry for a database transaction to be replayed to a row at a replica table. A row-ID value of the replication log entry is compared to a row-ID column value of the row at the replica table. The replication log entry is then replayed at a parallel log replayer based on the comparison. The database transaction is then committed to the replica table by replaying the associated transaction commit log entry at a transaction log replayer. | 05-26-2016 |
| 20160171070 | QUERY DISPATCHING SYSTEM AND METHOD | 06-16-2016 |
| 20160179917 | METHOD FOR STREAMING TRANSACTIONS IN DATABASE CLUSTER | 06-23-2016 |
| 20160378369 | PERFORMING POST-PROCESSING OPERATIONS FOR LOG FILE WRITES - A storage controller receives one or more host writes to a log file. A track is allocated to the log file. In response to completion of the one or more host writes to the log file, a determination is made that the track has remaining space. Data structures are reserved to avoid releasing the track having the remaining space to accommodate potential future writes to the log file in the remaining space of the track. | 12-29-2016 |
| 20190147077 | Funnel Locking For Sleepable Read-Copy Update | 05-16-2019 |
