International Business Machines Corporation

Kyndryl, Inc.

Nageswararao Venkata Gokavarapu

Raghavendran Srinivasan

Jithesh Moothoor

John Kurian

Madhu B Ananthapadmanabh

Hariharan N Venkitachalam

Badekila Ganesh Prashanth Bhat

Gopalakrishnan P

Parameswaran Selvam

Chaitanya Vutukuru

Srinivasan Raghavendran

Manjunath D

Arpana K Vishweshwarappa

Abel Palaty

Techniques for transaction tracking for a high availability architecture are described herein. An aspect includes receiving a first request from a client, the first request corresponding to a start of a transaction having transaction affinity. Another aspect includes, based on receiving the first request from the client, generating a transaction tracking token. Another aspect includes sending the first request with the transaction tracking token to a gateway. Another aspect includes receiving a first response corresponding to the first request from the gateway, the first response including middleware instance information corresponding to a middleware instance, wherein a plurality of subsequent requests from the client corresponding to the transaction are processed by the middleware instance corresponding to the middleware instance information.

Transaction tracking for high availability architecture using a tracking token and middleware instance information

Inflight transactions having predictable pod failure in distributed computing environments are managed by integrating a transaction manager into pods having containers running applications in a distributed computing environment, wherein the transaction manager records a transaction log having data indicative of historical pod failure. A pod health check that is also integrated into the pods determines predictive pod failure scenarios from the data of historical pod failure in the transaction log. Pod health can be tracked using the pod health checker by matching the predictive pod failure scenarios to transaction calls. Calls may be sent to a load balancer for recovery of pod failure for transaction calling match the predictive pod failure scenarios. Pods can be configured recover for the predictive pod failure.

Machine learning to predict container failure for data transactions in distributed computing environment

Methods and systems for distributed transaction processing include assigning portions of a logical unit of work to one or more transaction participants. Resource usage information relating to the portions of the logical unit of work is tracked from the respective one or more transaction participants. A last participant is determined based on the tracked resource usage information using a processor. The logical unit of work is resolved. Resolving the logical unit of work includes sending a prepare flow to each of the transaction participants except the last participant to optimize resolution efficiency.

Dynamically optimizing flows in a distributed transaction processing environment

A method for dynamic transaction request grouping and allocation in a distributed transaction processing system. The method may implement interconnected transaction process monitors to manage the handling and servicing of transaction requests with respect to networked computing platforms of the distributed transaction processing system.

Transaction process management by dynamic transaction aggregation

Method and apparatus for predicting a transaction's outcome in a transaction processing environment are provided. A transaction request is received by a transaction processing monitor (TPM), where the transaction request comprises a plurality of tags. The TPM identifies historical prior transactions corresponding to the transaction request, and determines a plurality of historical tags associated with those historical transactions. The TPM then determines whether a predicted execution time exceeds the transaction request's timeout, and proceeds accordingly. If the predicted execution time exceeds the timeout value, the transaction is immediately returned as failed. The tags associated with a given transaction request are repeatedly updated as the request traverses the transaction processing system, and the transaction is repeatedly verified to ensure that it can still be completed successfully.

Predicting transaction outcome based on artifacts in a transaction processing environment

A method, computer program product, and a system where a processor(s), executing extended architecture as a service, obtains a request from an extended architecture compliant transaction manager, to execute a transaction affecting a resource manager not supported by the transaction manager, where the resource managed by the resource manager is selected from the group consisting of: an extended architecture compliant resource, and an extended architecture non-compliant resource, where the request comprises a transaction identifier, and where the transaction comprises extended architecture compliant calls. The processor(s) generates a connection, from the extended architecture as a service to the resource manager, where the connection comprises a connection identifier. The processor(s) maintains, in a log, the connection identifier, the transaction identifier, and a state of the transaction. The processor(s) executes the transaction on the resource managed by the resource manager, via the connection.

Extended architecture as a service to integrate resource and transaction managers

A technique relates to dynamically determining a transaction coordinator. A transaction processing middleware (TPM) coordinator receives TPM weightages of TPM participants, where the TPM coordinator has a TPM coordinator weightage, and where the TPM coordinator and TPM participants are executing a transaction instance. The TPM coordinator individually compares the TPM coordinator weightage to each of the TPM weightages of the TPM participants. In response to not one of the TPM weightages of the TPM participants being greater than the TPM coordinator weightage, the TPM coordinator is kept unchanged. In response to a given TPM weightage of the TPM weightages of the TPM participants being greater than the TPM coordinator weightage, the TPM coordinator changes a TPM coordinator function to a given TPM participant having the given TPM weightage such that the given TPM participant is an interim TPM coordinator for the transaction instance.

Dynamically determine the transaction coordinator in multitier hybrid transaction processing middleware systems

Techniques for handling transactions are provided. A first transaction is received at an application system of a distributed system. The first transaction is completed, where completing the first transaction comprises writing a record to a queue. A response is generated by an application resource monitor (ARM) of the application system, where the response identifies the record and the application system. The response is transmitted to a transaction distribution system, where the transaction distribution system distributes transactions among application systems in the distributed system. A second transaction is received at the application system. Upon determining that the second transaction is a trigger transaction, the ARM determines a plurality of records that are associated with the second transaction, where the plurality of records includes the record. The ARM retrieves the record from the queue, and completes the second transaction based at least in part on the record.

Efficient handling of trigger transactions in a workload management environment

An approach is provided for providing transactional operations in an event-driven polyglot language runtime environment. Native functionalities of a transaction processing system are exposed as interfaces to multiple languages and frameworks in the runtime environment. The transactional operations are called from modules. The transaction processing system is integrated with the modules. A prepare operation is sent to a resource manager (RM) via a resolution thread. For a committed transaction outcome of the resolution thread, the commit is logged, an indication of the commit is sent to the RM, the commit is performed, a completion indication of the commit is sent, and a forget operation is logged. For a rollback transaction outcome of the resolution thread, the rollback is logged, an indication of the rollback is sent to the RM, the rollback is performed, a completion indication of the rollback is sent, and the forget operation is logged.

Integrating transaction processing system interfaces with event-driven polyglot runtime modules

Aspects of the present invention include methods, systems and computer program products. The method includes a processor coordinating an execution of a transaction between at least one compiler-type programming language transaction processing module (TPM) and at least one interpreter-type programming language TPM, wherein the at least one compiler-type TPM and the at least one interpreter-type TPM each have a proprietary protocol for communicating with other TPMs; maintaining session management information relating to the execution of a transaction, wherein the session management information comprises communication session identifiers for the proprietary protocol of each of the at least one interpreter-type TPM and the at least one compiler-type TPM; and mapping the communication session identifiers for the proprietary protocol of each of the at least one interpreter-type TPM and the at least one compiler-type TPM to facilitate communication between the at the least one interpreter-type TPM and the at least one compiler-type TPM.

Attach an interpreter-based TPM into a cluster of inter-connected multi-process based compiler-based TPMs to achieve global transaction

Embodiments of the present invention provide systems and methods for authenticating the source code of a software end product. The method includes generating a compound key, which is composed of a set of unique keys generated from a source file. A set of files are separately build based on a received source code, and a key generated and embedded into the files at the time of the build. A validation tool is used to compare the values of the generated compound key to the values of the embedded key to determine if the values match.

Source authentication of a software product

An approach is provided for providing transactional operations in an event-driven polyglot language runtime environment. Native functionalities of a transaction processing system are exposed as interfaces to multiple languages and frameworks in the event-driven polyglot language runtime environment. Application programming interfaces (APIs) are generated for the event-driven polyglot language runtime environment. Via the APIs, the transactional operations are called from modules within the event-driven polyglot language runtime environment. Based on the native functionalities of the transaction processing system being exposed and the transactional operations being called from the modules within the event-driven polyglot language runtime environment via the APIs, the transaction processing system is integrated with the modules within the event-driven polyglot language runtime environment.

Growing community of inventors

Bengaluru, India

Nageswararao Venkata Gokavarapu