Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Systems and methods for sharing transactional context between Java and traditional language applications are disclosed. In embodiments, a method comprises: receiving, by a computing device, a transaction request to execute a program, wherein the program comprises non-Java program components and Java program components; executing, by a transaction middleware of the computing device, the non-Java program components; contacting, by the transaction middleware, a resource manager server and registering with the resource manager server using global transaction ID data; transferring, by the transaction middleware of the computing device, the Java program components to a transaction coordinator of the computing device, along with thread ID data and the global transaction ID data; and storing, by the transaction coordinator, the thread ID data and global transaction ID data in a recoverable transaction log store.

Abstract: 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.

Abstract: 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.

Abstract: A two-phase commit online transaction processing system injects a set of test cases into a logical unit of work (LUW) associated with a transaction. Performance of the test cases, by respective transaction process monitors (TPMs), serves to predict the outcome of the LUW processes, before the TPMs vote with respect to committing or rolling back the transaction. The system contributes to improved transaction process quality assurance by detecting potential problems before the LUW is committed.

Abstract: A two-phase commit online transaction processing system injects a set of test cases into a logical unit of work (LUW) associated with a transaction. Performance of the test cases, by respective transaction process monitors (TPMs), serves to predict the outcome of the LUW processes, before the TPMs vote with respect to committing or rolling back the transaction. The system contributes to improved transaction process quality assurance by detecting potential problems before the LUW is committed.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: Systems and methods for sharing transactional context between Java and traditional language applications are disclosed. In embodiments, a method comprises: receiving, by a computing device, a transaction request to execute a program, wherein the program comprises non-Java program components and Java program components; executing, by a transaction middleware of the computing device, the non-Java program components; contacting, by the transaction middleware, a resource manager server and registering with the resource manager server using global transaction ID data; transferring, by the transaction middleware of the computing device, the Java program components to a transaction coordinator of the computing device, along with thread ID data and the global transaction ID data; and storing, by the transaction coordinator, the thread ID data and global transaction ID data in a recoverable transaction log store.

Abstract: 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.

Abstract: Aspects of the present invention include methods, systems and computer program products.

Abstract: Systems and methods for sharing transactional context between Java and traditional language applications are disclosed. In embodiments, a method comprises: receiving, by a computing device, a transaction request to execute a program, wherein the program comprises non-Java program components and Java program components; executing, by a transaction middleware of the computing device, the non-Java program components; contacting, by the transaction middleware, a resource manager server and registering with the resource manager server using global transaction ID data; transferring, by the transaction middleware of the computing device, the Java program components to a transaction coordinator of the computing device, along with thread ID data and the global transaction ID data; and storing, by the transaction coordinator, the thread ID data and global transaction ID data in a recoverable transaction log store.

Abstract: 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.

Abstract: 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.

Abstract: 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.