534 results about "Transaction log" patented technology

Method of and apparatus for collecting, storing, and retrieving data in a database management system. The database management system has an enterprise server and at least one workgroup user client. The method includes creating a transaction in a local database resident on said workgroup user client, entering the transaction into a transaction log resident on the workgroup user client, and creating a transaction file corresponding to the transaction log in an outbox of the workgroup user client. The workgroup user client transaction log is read, skipping those transactions which originate at the enterprise server, data files are created corresponding to the entries. The data files corresponding to transactions originating at the workgroup user client are read to an inbox on the enterprise server, thus updating the transactions into an enterprise database on the enterprise server.

A computer-implemented method and system for completing a transaction between a customer (10) and at least one merchant (20), including the steps of: (a) initiating a transaction by the customer (10) with a merchant (20); (b) communicating an authorization request, including customer data and transaction specific data, by the merchant (20) to a transaction system (26); (c) authenticating the customer (10) by the transaction system (26); (d) authorizing the transaction by the transaction system (26); (e) communicating the authorization response by the transaction system (26) to the merchant (20); and (f) completing the transaction between the merchant (20) and the customer (10). An apparatus for implementing the method is disclosed.

A file server provides transaction processing capabilities previously supplied by the operating system of a host computer. On-disk file system metadata is changed only at commit time, and a transaction log protects the transition. The disk state can only be a consistent state, resulting from a commit operation. All disk-block reservation and pre-allocation mapping are in the memory, and after a crash, they are automatically discarded. The file server therefore relieves the client of processing burden and also reduces network traffic. In addition, the file server can more efficiently perform the transaction processing capabilities and reduce the frequency of access to storage by judicious allocation of file system blocks and transfer of file system blocks between file system objects, cache memory, and the transaction log. The differentiation between preallocation states and allocation states of in-memory file system blocks also permits application programs to more efficiently transfer data between files.

A map-reduce compatible distributed file system that consists of successive component layers that each provide the basis on which the next layer is built provides transactional read-write-update semantics with file chunk replication and huge file-create rates. A primitive storage layer (storage pools) knits together raw block stores and provides a storage mechanism for containers and transaction logs. Storage pools are manipulated by individual file servers. Containers provide the fundamental basis for data replication, relocation, and transactional updates. A container location database allows containers to be found among all file servers, as well as defining precedence among replicas of containers to organize transactional updates of container contents. Volumes facilitate control of data placement, creation of snapshots and mirrors, and retention of a variety of control and policy information. Key-value stores relate keys to data for such purposes as directories, container location maps, and offset maps in compressed files.

A virtual database is attached to a server database management system (“DBMS”) such that the DBMS believes it needs to recover the database to a last known point of consistency. In order to perform this recovery, the DBMS requests the transaction log file entries to be read from what it believes is the database's transaction log file. However, the requests are intercepted and translated (unbeknownst to the DBMS) instead into requests to read the transaction log portion of the backup file. The DBMS then uses the transaction log records to bring the database to a point of transactional consistency, unaware that the log records are actually being sourced from the transaction log portion of the backup file. All changes made to the data during the recovery phase and later during the execution of any TSQL statements which insert, update, or delete data are routed into a cache file. Accordingly, a “virtual” database is created and used by the server DBMS engine as if it were a real database.

A disaster-tolerant data backup and remote copy system which is implemented as a controller-based replication of one or more LUNs (logical units) between two remotely separated pairs of array controllers connected by redundant links. In the situation wherein an array controller fails during an asynchronous copy operation, the partner array controller uses a ‘micro log’ stored in mirrored cache memory to recover transactions, in order, which were ‘missed’ by the backup storage array when the array controller failure occurred.

A system includes an active node and a standby node and zero or more replica nodes. Each of the nodes includes a database system, such as an in-memory database system. Client updates applied to the active node are written through to the standby node, and the standby node writes the updates through to a primary database and updates the replica nodes. Commit ticket numbers tag entries in transaction logs and are used to facilitate recovery if either of the active node or the standby node fails. Updates applied to the primary database are autorefreshed to the active node and written through by the active node to the standby node which propagates the updates to the replica nodes. Bookmarks are used to track updated records of the primary database and are used to facilitate recovery if either of the active node or the standby node fails.

System and method for sub-second data replication. The present invention provides the ability to replicate database transactions made on one computer to one or more local or remote computers instantly, utilizing the database management system's transaction log for the replication. The present invention intercepts transactions being sent to a database's transaction log and interprets and copies the transactions to one or more replica servers, as well as to the original existing database transaction log. This enables real-time reporting without taxing the transaction system, real-time backup and immediate disaster recovery, by offloading said activities from the transaction server to a replica server that synchronized with the transaction server in real-time. The system comprises a central server and a set of source and destination agents that can reside all in a local system, or can be remotely connected such as through a TCP / IP networks The central server controls a series of loadable modules to perform specific functions in the system, and an agent that runs on every machine in the system that has a relational database management system running. The agent is either a source agent, gathering data from a source database server, or a destination (or target) agent, applying the data to the destination database, or both a source and destination agent.

The invention discloses a distributed transaction processing method on a cloud computing platform. The method comprises the following steps that: at first, start base services in a data storage cluster of the cloud computing platform, and start transaction processing services on a node of a data management cluster; connect a client end to a data management service node by a RPC (Remote Procedure Call Protocol), request a new transaction, and a local transaction manager receives a request to instantiate a transaction object and assign a transaction identifier for sending to the client end; the client end issues a data operation request of the transaction, and the local transaction manager sends the request to a corresponding transaction object for processing according to the transaction identifier owned by the client end; the client end issues a transaction submitting command, and the local manager is responsible for submitting the transaction. The distributed transaction processing method is applied to the cloud computing platform, so that size of transaction logs and log operation times are reduced by caching and combining transaction logs; and moreover, a master lock and lease management solve a blocking problem; a strategy processing failure condition is recovered to maintain data consistency.

One embodiment of the present method and apparatus for synchronization of client transactions executed by an autonomous client enables a client operating on a limited connection to a server to log transactions executed against a locally stored server database state. Logged transactions are then synchronized with a current server database state by delivering the transaction log to the server, which re-executes each logged client transaction against the current server database state, thereby reducing synchronization-related transaction conflicts.

A system and method for managing transactions of application programs at a storage system enables data protection on a per-transaction basis. The storage system receives an instruction indicating a beginning of a transaction, and determines at least one primary volume for receiving data for the transaction. The storage system also provides a log volume for initially storing write data designated for the primary volume associated with the transaction. When the transaction is successfully completed the data stored in the log volume for the transaction is applied to the primary volume.

A method and mechanism is disclosed for implementing transaction logging in a database system. In-memory undo records are maintained to log undo information for the database system. Redo records are batch processed, with multiple redo records for a transaction stored on disk at commit time.

A system and method are provided for reimbursing merchants for coupons used by the customers of those merchants is disclosed. Pursuant to the Present Invention, a Coupon Data File is prepared, identifying the products potentially subject to coupons and / or incentives, and the nature of the associated discount. A Transaction Log Data File is also prepared, describing one or more purchase transactions undertaken by consumers. Finally, a Transaction Log Processor analyzes the transaction log data, compares the information in the Transaction Log Data File with information in the Coupon Data File and tabulates coupons redeemed by consumers during the transactions associated with the information in the Transaction Log Data.

The present invention captures streaming data and avoids continual retrieval. The invention only looks at data once, has a time dependency built into it, and data that is not consumed or relevant is discarded. The invention includes an engine processor that processes data according to stored information; stored rules that define engine operation, an input events module for receiving events which provides a plurality of events. Events are processed according to stored rules for generating a series of valid results when input events match the rules. Rule states that have been matched to an input event but have not produced a valid result are stored in state storage. The state of a rule as stored enables the engine to provide a valid result output upon a future reception of an input event necessary to complete the rule. Transaction log module monitors the operation of the engine for specified time period.

Various embodiments of a cluster of application servers in a networked computer system in which each application server includes a separate transaction manager instance are disclosed. In one embodiment, a separate transaction manager instance may be used to coordinate transactions initiated by an application component executing in process with the application server for a node of a cluster. If each transaction manager instance manages only transactions initiated within its own application server, then the loss of a single transaction manager instance may have no detrimental effect on transactions initiated in other nodes of the cluster. Further, if each transaction manager instance maintains its transaction logs in highly available memory accessible to all nodes of the cluster, in flight transactions of a failed node may be recovered by an instance in a different node.

A computer readable storage medium includes executable instructions to read source node transaction logs to capture transaction data, including local transaction data, global transaction identifiers and participating node data. The global transaction identifiers and participating node data are stored in target node queues. The target node queues are accessed to form global transaction data. Target tables are constructed based upon the local transaction data and the global transaction data.

A method for performing a consistency check on a database backup of a database is performed without requiring a full recovery of the original database from the database backup. Instead, a database view may be used as a smaller storage requirement tool for providing a transaction-consistent view of portions of an existing full database backup. The database view, in combination with the database backup and transaction log, contains all the information necessary to perform a consistency check on the database backup without a full reconstitution of the original database from the database backup. The consistency check may be run on the database view along with the database backup to verify the integrity of the full database backup to add improved reliability to a database recovery scheme.

A method and system for monitoring the consistency of replicated databases in a shared-nothing database cluster architecture is presented. The method involves the continuous monitoring of the database transaction logs that are maintained by the autonomous database managers that manage the individual database replicas in the cluster. In the event that data discrepancies are detected via the comparison of the transaction logs of the individual database replicas, remedial action is carried out according to configured rules in the main cluster controller. Additionally, if the database management system running within each node of the cluster possesses a database history file that records key events pertaining to a database replica, such as the occurrence of non-logged bulk loads of table data, or the modification of tables, a method can be instituted for the monitoring of the history files for discrepancies between the database replicas.

Apparatuses, systems, methods, and computer program products are disclosed for transaction log acceleration. A log module is configured to determine transaction log records indicating a sequence of operations performed on data. A commit module is configured to send transaction log records to one or more volatile memory pages accessible over a network. Volatile memory pages are configured to ensure persistence of transaction log records. A storage module is configured to send transaction log records to a non-volatile storage device in response to an acknowledgment that one or more volatile memory pages store the transaction log records.

In certain embodiments, a tiered storage system is disclosed that provides for failover protection during data backup operations. The system can provide for an index, or catalog, for identifying and enabling restoration of backup data located on a storage device. The system further maintains a set of transaction logs generated by media agent modules that identify metadata with respect to individual data chunks of a backup file on the storage device. A copy of the catalog and transaction logs can be stored at a location accessible by each of the media agent modules. In this manner, in case of a failure of one media agent module during backup, the transaction logs and existing catalog can be used by a second media agent module to resume the backup operation without requiring a restart of the backup process.

An exchange system for intangible goods comprises a first user system, a second user system, a registry system, a clearinghouse system and a hash module coupled for communication with each other. The first and second user systems includes a content module for acting as a repository for intangible goods, a pricing module for setting the price of intangible goods, a transaction generator module for creating transactions between seller and buyer, and a transaction log module for recording any transaction in which the user system participates. These systems are used to consummate transactions with other users for exchanging intangible goods. As part of each transaction, the user and the transaction must be entered or registered in the registry system. The registry system comprises an account module and a transaction log module for maintaining the anonymity of the sellers and buyers. The hash module is used by the other modules to generate unique hash codes that are used to access transactions and to validate users. The clearinghouse system includes an account module, an audit module, and a transaction log module for clearing and posting transactions once they have been verified between two users.

A highly available transaction recovery service migration system in accordance with one embodiment of the present invention implements a server's Transaction Recovery Service (TRS) as a migratable service. In one embodiment of the present invention, the TRS is a server instance or software module implemented in JAVA. The TRS migrates to an available server that resides in the same cluster as the failed server. The migrated TRS obtains the TLOG of the failed server, reads the transaction log, and performs transaction recovery on behalf of the failed server. The migration may occur manually or automatically on a migratable services framework. The TRS of the failed server migrates back in a fail back operation once the failed primary server is restarted. Failback operation may occur whether recovery is completed or not. This expedites recovery and improves availability of the failed server thereby preserving the efficiency of the network and other servers.

Embodiments described herein generally relate to providing durability of in memory columnar datastores using multiple logs. A computer-implemented method is described. The method includes receiving a request to perform a transaction involving multiple tables in a column-oriented database system. The method further includes performing the transaction on each of the two or more database tables. Performance of the transaction generates two or more commit fragments corresponding to each of the two or more database tables. The method further includes writing each commit fragment to a transaction log for each of the two or more database tables. The method also includes writing a commit record for the transaction to a commit log after all commit fragments have been written.

System resources (e.g., objects or other resources) are managed to provide multiple levels of undo and / or support for delegation of updates on main-memory resident objects accessible by concurrent transactions. For example, a log associated with each transaction stores information regarding an update to an object when the object is locked in an update mode (e.g., a write mode) by the transaction. The transaction can be rolled back by restoring information from the log of the transaction to the object. If the transaction commits, then the log may be destroyed. If the transaction delegates to another transaction, the log of the transaction is also delegated. A record codelet can be automatically generated to perform the storing of information in the log, and a restore codelet can be automatically generated to undo updates by restoring information from the log to the updated objects. The codelets may be specific to each class of objects. Lock state information is used to identify undo information age so that the undo information may be stored in the log without regard to order, thereby enhancing the speed of the recording process.

A method implemented in an online transaction processing system is disclosed. The method includes, upon a read request from a transaction process, reading a transaction log, reading data stored in a storage without accessing the transaction log, and constituting a current snapshot using the data in the storage and the transaction log. The method also includes, upon a write request from the transaction process, committing transaction by accessing the transaction log. The method also includes propagating update in the commit to the data in the storage asynchronously. The transaction commit is made successful upon applying the commit to the transaction log. Other methods and systems also are disclosed.