Support #634

review global transaction abort rules when particpated server fails

Added by Madars 3 months ago. Updated 2 months ago.

Status:NewStart date:02/22/2021
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

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.

4. When new DB joins the global transaction, currently it is reported to tmsrv only after then join. The proper way would be to report tmsrv before join. So that if timeout occurs at the particular moment at the tmsrv, but server did not yet join (some race condition between tmsrv & server), then after the tmsrv timeout, that particular transaction branch may be orphaned. Thus tmsrv will not perform timeout, as transaction is completed and is not aware of some transaction branch. Orphan txn may be rolled back by either resource manager (DB) timeout or xadmin recoverlocal / xadmin abortlocal.

5. Error codes for tpresume() in case if transaction is expired and we perform fresh join (currently we get TPESYSTEM, probably needs to be TPEINVAL).

History

#1 Updated by Madars 2 months ago

  • Description updated (diff)

#2 Updated by Madars 2 months ago

  • Description updated (diff)

#3 Updated by Madars 2 months ago

  • Description updated (diff)

#4 Updated by Madars 2 months ago

  • Description updated (diff)

#5 Updated by Madars 2 months ago

  • Description updated (diff)

Also available in: Atom PDF