Support #634
Updated by Madars about 3 years ago
1. tpcall() return code shall analysed in order to decide when global transaction shall be aborted.
Current logic of aborting global transaction for any error code seems to be too aggressive.
2. Secondly rules for tpcommit/tpabort/tpsuspend/tpresume must be described, when after an error (and what error) process still is in transaction.
Currently seems that tpcommit/tpabort after an error will put processes outside of the transaction. For others needs to be defined and logic must be clarified / updated to have some logical outcomes.
3. Consider caching the transaction outcomes, if for example web service performs re-attempted commits, due to timeout.
Current logic of aborting global transaction for any error code seems to be too aggressive.
2. Secondly rules for tpcommit/tpabort/tpsuspend/tpresume must be described, when after an error (and what error) process still is in transaction.
Currently seems that tpcommit/tpabort after an error will put processes outside of the transaction. For others needs to be defined and logic must be clarified / updated to have some logical outcomes.
3. Consider caching the transaction outcomes, if for example web service performs re-attempted commits, due to timeout.