Scout XA Transactions with MariaDB Cluster [message #1871424] |
Tue, 24 September 2024 05:43  |
Eclipse User |
|
|
|
Hi there,
We are considering migrating our database to a MariaDB cluster, but stumbled upon the restriction that XA transactions do not work on the MariaDB cluster (see: https://mariadb.com/kb/en/xa-transactions/). But Scout's TwoPhaseTransactionCommitProtocol does actually implement the XA specification. Do you guys have any experience with Scout and MariaDB Cluster? Do DB transaction just not work? Does the TwoPhaseTransactionCommitProtocol correspond to the kind of XA transactions that don't work and can we configure this somehow?
Best regards,
Jérôme
|
|
|
Re: Scout XA Transactions with MariaDB Cluster [message #1871619 is a reply to message #1871424] |
Wed, 02 October 2024 10:17   |
Eclipse User |
|
|
|
If the database does not support XA transactions, there is not "magic" that you can apply externally to make it XA compliant.
The two phase commit protocol itself is quite simple. It is designed to atomically commit or rollback changes to a distributed system. In phase 1, you first ask each participant if they would be ready to commit the changes. If one of them answers "No" (or not at all), the transaction is aborted. If all participants answer "Yes", the transaction is commited (phase 2). The crucial point is, that the protocol specifies that this second phase is not allowed to fail. This is what makes the protocol more of a theoretic ideal, because in the real world, there could always be a problem, such as a hardware failure.
Scout associates each request with an "transaction" that can accept one or more "transaction members". At the end of the request, the TwoPhaseTransactionCommitProtocol is used to commit or rollback all members of the transaction. Typical members are database connections and messaging operations (MOM, e.g. for cluster notifications). Most APIs don't allow properly following the two phase commit protocol, therefore usually only one of the phases is implemented (see implementations of AbstractTransactionMember).
Do you actually need to cluster your database? I believe, many applications work just fine with a single database and multiple application servers.
Beat
|
|
|
|
Powered by
FUDForum. Page generated in 0.04263 seconds