Disclosed herein are system, method, and computer program product embodiments for utilizing an intrusive data hash table to support processing transactions. An embodiment operates by receiving a transaction comprising a plurality of operations. Responsive to the receiving, the transaction is verified by verifying the validity of the plurality of operations. Responsive to verifying the transaction, the transaction is applied to the intrusive hash table.
Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A computer implemented method for transaction support through an intrusive hash table, comprising: receiving a transaction comprising a plurality of operations that need to be verified before being committed, wherein each of the plurality of operations is associated with a key, an operation type, and a next pointer; verifying a validity of the transaction by searching the intrusive hash table and previous operations of the transaction to verify a validity of each operation from the plurality of operations, wherein the intrusive hash table stores a plurality of nodes representing operations of previously-verified transactions, wherein the operation is verified based on looking up the key in the intrusive hash table and searching the plurality of operations for another operation associated with the key and identifying the operation type of the operation; applying, responsive to verifying the transaction, the transaction to the intrusive hash table; and wherein at least one of the receiving, verifying, and applying are preformed by one or more computers.
A computer system uses an "intrusive hash table" for processing transactions involving multiple operations. Each operation has a key, an operation type (like insert, delete, update), and a "next pointer". Before applying a transaction, the system verifies each operation by checking its validity against the intrusive hash table (which stores past, verified operations) and against other operations within the same transaction. Verification involves looking up the operation's key in the hash table and checking the operation type. Only verified transactions are applied to the hash table.
2. The method of claim 1 , wherein the applying further comprises: routing next pointers associated with the plurality of operations; and routing next pointers associated with nodes of the plurality of nodes affected by applying the transaction.
In the transaction processing system using an intrusive hash table (as described in the previous claim), applying a verified transaction to the hash table involves updating "next pointers". Specifically, the system updates the "next pointers" associated with the operations within the transaction itself, and also updates the "next pointers" of any existing nodes in the hash table that are affected by the transaction. This pointer manipulation helps to maintain the integrity and efficiency of the intrusive hash table structure as new transactions are processed.
3. The method of claim 1 , further comprising: failing to verify an operation of the plurality of operations in the transaction; halting, responsive to the failing, verification a unverified operations of the plurality of operations; and proceeding to receive and process another transaction without undoing verification of previously verified operations.
In the transaction processing system using an intrusive hash table (as described in the first claim), if any operation within a transaction fails verification, the system immediately stops verifying any remaining operations in that transaction. Importantly, the system does *not* undo the verification of any operations that were *already* successfully verified within the transaction. The system then proceeds to receive and process a completely new and separate transaction, while preserving the verified operations from the previous, failed transaction attempt.
4. The method of claim 1 , wherein the operation type is a selected one of an insert operation, a delete operation, an update operation, and a no-op operation.
In the transaction processing system using an intrusive hash table (as described in the first claim), each operation is associated with an "operation type." The possible operation types are: "insert" (add new data), "delete" (remove existing data), "update" (modify existing data), and "no-op" (do nothing). The system uses these operation types during transaction verification to ensure the consistency and validity of the data within the intrusive hash table.
5. The method of claim 1 , wherein the next pointer is used to cache a result of the looking up.
In the transaction processing system using an intrusive hash table (as described in the first claim), each operation has a "next pointer." This "next pointer" is used to store, or cache, the result of looking up the operation's key in the intrusive hash table during the verification process. This caching mechanism can improve performance by avoiding redundant lookups for operations that are related or dependent on each other within the same transaction or across multiple transactions.
6. The method of claim 1 , wherein verifying the validity of an operation from the plurality of operations further comprises: identifying the operation is associated with a previously verified operation of the plurality of operations by comparing the key with a previous key of the previously verified operation; assigning the next pointer to point to the previously verified operation in the intrusive hash table; and converting the operation and the previously verified operation into two equivalent operations.
In the transaction processing system using an intrusive hash table (as described in the first claim), verifying an operation involves identifying if that operation is related to a *previously* verified operation. This is done by comparing the operation's key with the key of previously verified operations. If a related operation is found, the system assigns the "next pointer" of the current operation to point to the previously verified operation in the hash table. Then, the system transforms the current operation and the previously verified operation into "equivalent" operations.
7. The method of claim 6 , wherein the converting comprises: assigning an operation type of the at least one of the equivalent operations to a no-op operation type, wherein the at least one of the equivalent operations is not processed.
In the transaction processing system using an intrusive hash table (as described in the previous claim), converting a pair of related operations into equivalent operations involves setting the operation type of *one* of those operations to "no-op". The operation marked as "no-op" is then effectively ignored, meaning it will *not* be processed further. This mechanism is used to handle conflicts or dependencies between operations, ensuring data consistency and correctness within the intrusive hash table.
8. A system, comprising: a memory storing transactions; and at least one processor coupled to the memory and configured to: receive a transaction comprising a plurality of operations that need to be verified before being committed, wherein each of the plurality of operations is associated with a key, an operation type, and a next pointer; verifying a validity of the transaction by searching the intrusive hash table and previous operations of the transaction to verify a validity of each operation from the plurality of operations, wherein the intrusive hash table stores a plurality of nodes representing operations of previously-verified transactions, wherein the operation is verified based on looking up the key in the intrusive hash table and searching the plurality of operations for another operation associated with the key and identifying the operation type of the operation; and apply, responsive to verifying the transaction, the transaction to the intrusive hash table.
A computer system for processing transactions utilizes memory and a processor. The processor receives transactions comprised of multiple operations that each need to be verified. Each operation has a key, an operation type (like insert, delete, update), and a "next pointer". The processor verifies each operation against an intrusive hash table (which stores past, verified operations) and against other operations within the same transaction. Verification involves looking up the operation's key in the hash table and checking the operation type. Only verified transactions are applied to the hash table.
9. The system of claim 8 , wherein to apply the transaction the at least one processor is configured to: routing next pointers associated with the plurality of operations; and routing next pointers associated with nodes of the plurality of nodes affected by applying the transaction.
In the transaction processing system using an intrusive hash table (as described in the previous claim), when the processor applies a verified transaction to the hash table, it updates "next pointers." Specifically, the processor updates the "next pointers" associated with the operations within the transaction itself, and also updates the "next pointers" of any existing nodes in the hash table that are affected by the transaction. This pointer manipulation helps to maintain the integrity and efficiency of the intrusive hash table structure.
10. The system of claim 8 , wherein the at least one processor is further configured to: halt, responsive to the failing to verify an operation of the plurality of operations, the verification of unverified operations of the plurality of operations; and process another transaction without undoing verification of previously verified operations.
In the transaction processing system using an intrusive hash table (as described in the eighth claim), if the processor fails to verify an operation within a transaction, it stops verifying any remaining operations in that transaction. Importantly, the processor does *not* undo the verification of any operations that were *already* successfully verified within the transaction. The processor then proceeds to process a completely new and separate transaction while retaining the verified operations from the previous, failed transaction attempt.
11. The system of claim 8 , wherein the operation type is a selected one of an insert operation, a delete operation, an update operation, and a no-op operation.
In the transaction processing system using an intrusive hash table (as described in the eighth claim), each operation is associated with an "operation type." The possible operation types are: "insert" (add new data), "delete" (remove existing data), "update" (modify existing data), and "no-op" (do nothing). The processor uses these operation types during transaction verification to ensure data consistency and validity within the intrusive hash table.
12. The system of claim 8 , wherein the next pointer is used to cache a result of the looking up.
In the transaction processing system using an intrusive hash table (as described in the eighth claim), each operation has a "next pointer." This "next pointer" is used to store, or cache, the result of looking up the operation's key in the intrusive hash table during the verification process. This caching mechanism improves performance by avoiding redundant lookups for operations that are related or dependent on each other within the same transaction or across multiple transactions.
13. The system of claim 8 , wherein to verify the validity of an operation from the plurality of operations the at least one processor is further configured to: identifying the operation is associated with a previously verified operation of the plurality of operations by comparing the key with a previous key of the previously verified operation; assign the next pointer to point to the previously verified operation in the intrusive hash table; and convert the operation and the previously verified operation into two equivalent operations.
In the transaction processing system using an intrusive hash table (as described in the eighth claim), when verifying an operation, the processor identifies if that operation is related to a *previously* verified operation. This is done by comparing the operation's key with the key of previously verified operations. If a related operation is found, the processor assigns the "next pointer" of the current operation to point to the previously verified operation in the hash table. Then, the processor transforms the current operation and the previously verified operation into "equivalent" operations.
14. The system of claim 13 , wherein to convert the operation and the previously verified operation, the at least one processor is further configured to: assign an operation type of the at least one of the equivalent operations to a no-op operation type, wherein the at least one of the equivalent operations is not processed.
In the transaction processing system using an intrusive hash table (as described in the previous claim), when converting a pair of related operations into equivalent operations, the processor sets the operation type of *one* of those operations to "no-op". The operation marked as "no-op" is then effectively ignored, meaning it will *not* be processed further. This is to handle conflicts or dependencies between operations, ensuring data consistency and correctness within the intrusive hash table.
15. A non-transitory computer-readable device having instructions stored thereon that, when executed by at least one computing device, causes the at least one computing device to perform operations comprising: receiving a transaction comprising plurality of operations that need to be verified before being committed, wherein each of the plurality of operations is associated with a key, an operation type, and a next pointer; verifying a validity the transaction by searching the intrusive hash table and previous operations of the transaction to verify a validity of each operation from the plurality of operations, wherein the intrusive hash table stores a plurality of nodes representing operations of previously-verified transactions, wherein the operation is verified based on looking up the key in the intrusive hash table and searching the plurality of operations for another operation associated with the key and identifying the operation type of the operation; applying, responsive to verifying the transaction, the transaction to the intrusive hash table; and wherein at least one of the receiving, verifying, and applying are preformed by one or more computers.
A computer-readable storage device holds instructions for processing transactions with an "intrusive hash table". The instructions cause a computer to: receive a transaction comprising multiple operations that need to be verified. Each operation has a key, operation type, and "next pointer". The computer verifies each operation against the intrusive hash table (which stores past, verified operations) and against other operations within the same transaction, using the key and operation type. If all operations verify, the computer applies the transaction to the hash table.
16. The computer-readable device of claim 15 , the verifying of an operation from the plurality of operations comprises: identifying the operation is associated with a previously verified operation of the plurality of operations by comparing the key with a previous key of the previously verified operation; assigning the next pointer to point to the previously verified operation in the intrusive hash table; and converting the operation and the previously verified operation into two equivalent operations, wherein at least one of the equivalent operations is associated with a no-op operation type, and wherein the at least one of the equivalent operations is not processed.
In the transaction processing system using an intrusive hash table (as described in the previous claim), the instructions stored on the computer-readable device further define how to verify an operation: If an operation is related to a previously verified operation (based on comparing keys), the "next pointer" of the current operation points to the previous one. Then, the two operations are converted into equivalent operations by assigning a "no-op" operation type to one of them, preventing it from being processed, thus resolving conflicts.
Cooperative Patent Classification codes for this invention. Click any code to explore related patents in that topic.
September 4, 2014
May 2, 2017
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.