Hi, Sergey! On Oct 07, Sergey Vojtovich wrote:
Hi Sergei,
yes, there are many reasons why cohort may fail during commit phase. Spider has a lot reasons too. In this particular case (test case provided by Elena) it fails with the following error: ERROR 42S02: Table 'mysql.spider_xa' doesn't exist
Anyway it is not clear how to handle cohort commit failure properly. Let's say we have 4 cohorts participating in XA transaction. Cohort 2 and 3 fail.
there're two distinct XA use cases. 1. mariadb works as transaction coordinator, when a transaction involves two or more xa-capable storage engines or binlog. 2. there is an external (to this mariadb instance) transaction coordinator, that uses XA START, XA COMMIT, etc commands. In the second case mariadb is simply one of the cohorts, it doesn't know the big picture and when it fails - it fails, it's up to the transaction coordinator to recover from this situation. On the other hand, a failure at XA COMMIT is a catastrophic event: XAER_RMERR: Fatal error occurred in the transaction branch - check your data for consistency So if the engine fails in some way that does not impact data consistency, then it's preferrable if it wouldn't scare the user with XAER_RMERR, but report that commit was successful and return an error on the next statement. Regards, Sergei