Abstract: A coordinator module for improving communications within a cloud computing system is disclosed. The coordinator module initiates transaction requests by generating a coordination context, where the coordination context includes a transaction context, a coordination type, and an initiator supplemental address. The coordinator module includes a supplemental address handler for creating the initiator supplemental address that unique identifies the coordinator module and the associated pod. The coordinator module receives transaction responses, where the transaction response includes a coordination context. The coordinator module includes a transaction context checker to verify that the transaction response was not received in error, by comparing the received transaction context with a saved transaction context. The coordinator module includes a registration bridge that identifies an alternate coordinator module and alternate pod to process the transaction response if the transaction contexts do not match.

Abstract: Transaction recovery in a cloud computing environment. Transaction recovery includes determining whether a first container of a plurality of containers in the cloud computing environment is crashed. In response to the first container being crashed, the method may include determining at least one transaction log entry from a first log file corresponding to the first container. Transaction recovery includes retrieving at least one in-doubt transaction corresponding to the first container from a first database corresponding to the first container. Transaction recovery includes comparing the at least one transaction log entry with the at least one in-doubt transaction for transaction recovery.

Abstract: Transaction recovery in a cloud computing environment. Transaction recovery includes determining whether a first container of a plurality of containers in the cloud computing environment is crashed. In response to the first container being crashed, the method may include determining at least one transaction log entry from a first log file corresponding to the first container. Transaction recovery includes retrieving at least one in-doubt transaction corresponding to the first container from a first database corresponding to the first container. Transaction recovery includes comparing the at least one transaction log entry with the at least one in-doubt transaction for transaction recovery.

Abstract: A method, computer system, and computer program product for determining a candidate patch for computer software is provided. According to a method, fingerprint(s) of patch(es) for a computer software is obtained first, wherein a fingerprint of a patch comprises function(s) being revised in the computer software if the patch is installed into the computer software. Then whether every function in the obtained fingerprint(s) of patch(es) has been called is monitored in response to beginning of execution of the computer software along to code path(s) related to bug(s). And at last candidate patch(es) is determined in response to end of the execution of the computer software along to the code path(s) related to the bug(s), wherein every function in the fingerprint of the candidate patch(es) has been called during the execution of the computer software.

Abstract: A process instances guard system for managing the execution of process instances based on statuses of other process instances in a business process management (BPM) engine is disclosed. The process instances guard system provides a plurality of policies for managing the execution of process instances. When a status change event related to an existing process instance is received, the process instances guard system matches the existing process instance with a policy. After determining that the existing process instance matches the prerequisite condition of a policy, the process instances guard system determines that a plurality of existing process instances match the policy target descriptor of the policy, and executes the action of the policy on the plurality of existing process instances.

Abstract: A method, computer system, and computer program product for determining a candidate patch for computer software is provided. According to a method, fingerprint(s) of patch(es) for a computer software is obtained first, wherein a fingerprint of a patch comprises function(s) being revised in the computer software if the patch is installed into the computer software. Then whether every function in the obtained fingerprint(s) of patch(es) has been called is monitored in response to beginning of execution of the computer software along to code path(s) related to bug(s). And at last candidate patch(es) is determined in response to end of the execution of the computer software along to the code path(s) related to the bug(s), wherein every function in the fingerprint of the candidate patch(es) has been called during the execution of the computer software.

Abstract: A method, computer system, and computer program product for determining a candidate patch for computer software is provided. According to a method, fingerprint(s) of patch(es) for a computer software is obtained first, wherein a fingerprint of a patch comprises function(s) being revised in the computer software if the patch is installed into the computer software. Then whether every function in the obtained fingerprint(s) of patch(es) has been called is monitored in response to beginning of execution of the computer software along to code path(s) related to bug(s). And at last candidate patch(es) is determined in response to end of the execution of the computer software along to the code path(s) related to the bug(s), wherein every function in the fingerprint of the candidate patch(es) has been called during the execution of the computer software.

Abstract: A method, computer system, and computer program product for determining a candidate patch for computer software is provided. According to a method, fingerprint(s) of patch(es) for a computer software is obtained first, wherein a fingerprint of a patch comprises function(s) being revised in the computer software if the patch is installed into the computer software. Then whether every function in the obtained fingerprint(s) of patch(es) has been called is monitored in response to beginning of execution of the computer software along to code path(s) related to bug(s). And at last candidate patch(es) is determined in response to end of the execution of the computer software along to the code path(s) related to the bug(s), wherein every function in the fingerprint of the candidate patch(es) has been called during the execution of the computer software.

Abstract: A process instances guard system for managing the execution of process instances based on statuses of other process instances in a business process management (BPM) engine is disclosed. The process instances guard system provides a plurality of policies for managing the execution of process instances. When a status change event related to an existing process instance is received, the process instances guard system matches the existing process instance with a policy. After determining that the existing process instance matches the prerequisite condition of a policy, the process instances guard system determines that a plurality of existing process instances match the policy target descriptor of the policy, and executes the action of the policy on the plurality of existing process instances.

Abstract: Embodiments of the present invention provide methods and systems for simulating variable changes during runtime of a process. The method includes recording variable changes and process context, and filtering sensitive content from the variable changes and process context. The recorded variable changes are recorded into a timeline containing the change in values to the variable changes, which is executed in a simulation environment, in order to debug the process.

Abstract: Embodiments of the present invention provide methods and systems for simulating variable changes during runtime of a process. The method includes recording variable changes and process context, and filtering sensitive content from the variable changes and process context. The recorded variable changes are recorded into a timeline containing the change in values to the variable changes, which is executed in a simulation environment, in order to debug the process.