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

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

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.

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

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

Abstract: An embodiment of the invention may include a method, computer program product and system for processing a transaction. The embodiment may include receiving a transaction request by a first transaction processing monitor from a plurality of transaction processing monitors. The transaction request contains details for updating a global database. The embodiment may include determining whether the global database has begun updating based on the transaction request. Determining whether the global database has begun updating includes checking a transaction state database. The embodiment may include determining that the global database has not begun updating, and updating an entry in the global database based on the details contained in the transaction request.

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.