A method includes saving a control state for a processor in response to commencing a transactional processing sequence, wherein saving the control state produces a saved control state. The method also includes permitting updates to the control state for the processor while executing the transactional processing sequence. Examples of updates to the control state include key mask changes, primary region table origin changes, primary segment table origin changes, CPU tracing mode changes, and interrupt mode changes. The method also includes restoring the control state for the processor to the saved control state in response to encountering a transactional error during the transactional processing sequence. In some embodiments, saving the control state comprises saving the current control state to memory corresponding to internal registers for an unused thread or another level of virtualization. A corresponding computer system and computer program product are also disclosed herein.

Methods and systems of applying retroactive adjustments to financial data. An example method includes: receiving one or more adjustment records associated with a financial account; saving a snapshot of the financial account, the snapshot comprising a plurality of transaction records reflecting previously processed transactions associated with the financial account; merging the adjustment records and the transaction records to produce a plurality of adjusted transaction records; processing adjusted transaction records to produce an updated state of the financial account; comparing the saved snapshot to the updated state of the financial account to produce one or more adjustment events; and processing the adjustment events using one or more event processing rules.

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. As the transactions are received, the transactions may be analyzed to detect duplicate transactions and/or errors in the transactions. The transaction exchange platform may take steps to remediate transactions that are recognized as duplicates or predicted to generate one or more errors. Similarly, the transaction exchange platform may take steps to remediate transactions that are rejected by a clearinghouse.

A method for execution of a Byzantine Fault Tolerant (BFT) protocol among a number of participating nodes of a network includes: receiving, by a primary node of the BFT protocol, a transaction request, applying, by the primary node, a data dissemination protocol for distributing the transaction request among the participating nodes via a data-plane of the network, and generating, by the primary node, a hash of the transaction request and requesting consensus among the participating nodes via a control-plane of the network using the hash of the transaction request.

A method for enabling data set changes to be reverted to a prior point in time or state is disclosed. In one embodiment, such a method includes providing a data set comprising one or more data elements and a specified number of generations of the data elements. In certain embodiments, the data set is a partitioned data set extended (PDSE) data set, and the data elements are “members” within the PDSE data set. The method further includes tracking changes made by a job to data elements of the data set. The method further references, in a data structure (also referred to herein as a “cluster”) associated with the job, previous generations of the data elements changed by the job. In certain embodiments, the data structure is stored in the data set. A corresponding system and computer program product are also disclosed.

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. As the transactions are processed, the transactions may require access to a resource (e.g., a key value in a database). A microservice processing the transaction may request, from a locking microservice, a lock for the resource. The locking microservice may query a local cache to determine whether a lock exists for the resource. If the local cache determines that no lock exists for resource, the locking mechanism may employ a consensus protocol to obtain a lock for the resource from a plurality of clusters. If consensus is reached, a lock for the resource may be granted to the requesting microservice.

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. As the transactions are processed, the transactions may require access to a resource (e.g., a key value in a database). A microservice processing the transaction may request, from a locking microservice, a lock for the resource. The locking microservice may query a local cache to determine whether a lock exists for the resource. If the local cache determines that no lock exists for resource, the locking mechanism may employ a consensus protocol to obtain a lock for the resource from a plurality of clusters. If consensus is reached, a lock for the resource may be granted to the requesting microservice.

Aspects described herein may relate to a transaction exchange platform using a streaming data platform (SDP) and microservices to process transactions according to review and approval workflows. The transaction exchange platform may receive transactions from origination sources, which may be added to the SDP as transaction objects. Microservices on the transaction exchange platform may interact with the transaction objects based on configured workflows associated with the transactions. Processing on the transaction exchange platform may facilitate clearing and settlement of transactions. Some aspects may provide for dynamic and flexible reconfiguration of workflows and/or microservices. Other aspects may provide for data snapshots and workflow tracking, allowing for monitoring, quality control, and auditability of transactions on the transaction exchange platform.

Techniques are disclosed herein for identifying, recording and restoring the state of a database session and various aspects thereof. A session template data structure is generated that includes session attribute values describing various aspects of the session that is established between a client system and a database management system (DBMS and enables the client system to issue to the DBMS commands for execution. Based on the session attribute values, DBMS may generate a template identifier corresponding to the session template data structure. The template identifier may be stored in an association with the session state that it partially (or in whole) represents. In an embodiment, when another state of a session is captured, if the template identifier for the state is the same, then rather than storing the attribute-value pairs for the other state, the template identifier is further associated with the other state. In an embodiment, a request boundary is detected where the session is known to be at a recoverable point. If recovery of the session is needed, the session state is restored, and replay of commands start from this point. Each command replayed is verified to produce the same session state as it produced at original execution. If the session is determined to be a safe point, then all the commands recorded for replay prior to the safe point may be deleted. In an embodiment, the template is used to set the initial state when borrowing from a session pool The state tracking is also used to know that the session can be failed over safely during planned operation as the session is unlikely to drain by itself even when not used.

A transaction consensus processing method for a blockchain is provided. A target node that initiates a proposition performs compression processing on proposed transaction data based on a compression algorithm, and fragments the compressed transaction data into a number of data fragments based on an erasure code algorithm. The method includes: receiving a data fragment of the transaction data that is sent by the target node in a unicast mode, data fragments sent by the target node to nodes in the unicast mode being different; broadcasting the received data fragment to other nodes, and receiving data fragments of the transaction data that are broadcast by the other nodes; performing data recovery on the received data fragment based on an erasure code reconstruction algorithm, performing decompression processing on the recovered transaction data based on a decompression algorithm to obtain original content of the transaction data, and completing the consensus.