FAQ

Can SOFAStack be deployed on virtual machines or physical servers?

Yes. SOFAStack supports deployment on physical servers and virtual machines (VMs).

Does SOFAStack currently support only Alibaba Cloud Apsara ACK?

SOFAStack supports deployment in multicloud and heterogeneous environments. It currently supports environments such as Huawei Cloud and open source OpenStack.

Which databases does the distributed transaction service support?

The distributed transaction service currently supports mainstream databases such as MySQL, Oracle, RDS MySQL, and PostgreSQL.

Does the distributed transaction service support deployment in a VPC?

Yes. If you need this feature, contact technical support.

If the distributed transaction service goes down, can transactions be rolled back correctly?

The server-side of the distributed transaction service records and persists the status of transactions. Even if the service goes down, transactions can still be rolled back correctly after the service restarts.

Can SQL keywords be used as column names when creating a table?

No. Do not use SQL keywords, such as DESC or TABLE, as column names when you create a table.

What are the dependencies for using the distributed transaction service?

If you use the distributed transaction feature in the data access proxy, no dependencies are required because the data access proxy is deeply integrated with the distributed transaction service. You can start a transaction with a single SQL statement.

If you use the distributed transaction service based on the software development kit (SDK), you must add the required dependencies to the pom.xml file of the imported distributed transaction SDK. For more information, see the developer guide.

After the distributed transaction service is enabled, can SOFAStack, Dubbo, MSMQ, the data access proxy, RDS, MySQL, Oracle, and OceanBase be included in a distributed transaction?

Yes. The distributed transaction service supports integrated transactions across SOFAStack, Dubbo, MSMQ, the data access proxy, RDS, MySQL, Oracle, and OceanBase.

Service A calls Service B. A distributed transaction annotation is added to Service A, but not to Service B. Are Service A and Service B in the same distributed transaction?

Service A and Service B are in the same transaction. If the distributed transaction annotation is added to the function of Service A, all services called by the annotated function and their sub-calls are included in the transaction of Service A.

Does the distributed transaction service support high availability across multiple data centers?

The distributed transaction service supports active-active disaster recovery within the same city and active geo-redundancy for high availability (HA). If an entire data center becomes unavailable due to unexpected events such as network failures or power outages, the distributed transaction service can switch to a standby data center to continue providing services.

How do I check if the network connectivity between the distributed transaction SDK and the transaction cloud service is normal?

On the transaction cloud service, you can run netstat -an | grep 14200 to check for TCP connections. If a TCP connection exists, the transaction cloud service is running correctly. Otherwise, the service is down or the network is disconnected.

The network connectivity between the distributed transaction SDK and the transaction cloud service is normal, but communication fails. Why?

A normal TCP connection indicates that the transaction cloud service is running correctly.

If communication between the distributed transaction SDK and the transaction cloud service returns a failure message, this indicates that the message sent from the SDK to the service violates certain constraints. You can search for the specific failure message in the dtx-rpc.log file using the transaction ID.

How do I view the logs of the distributed transaction service?

The transaction logs of the distributed transaction service are stored in ${user.home}/logs/dtx-xxx.log. ${user.home} is the root directory of the user account that starts the distributed transaction SDK. Different log files contain different content:

• dtx-client.log: Contains logs about the SDK startup and the execution of all transactions.

• dtx-rpc.log: Contains all communication information between the SDK and the server-side of the distributed transaction service.

• dtx-parser.log: Contains logs for SQL statement syntax parsing.

• dtx-rm.log: Contains the two-phase execution logs for all participants (TCC, FMT).

• dtx-datasource.log: Contains transaction execution logs in FMT mode.

When you view the logs, you can search by the transaction ID to see which resources were accessed by the transaction in the SDK and check its commit and rollback status.

Is the TCC @TwoPhaseBusinessAction annotation effective if it is placed on the implementation class of an interface?

No, it is not. The annotation must be placed on the interface, not on the implementation class.

   public interface UserFacade{

        @TwoPhaseBusinessAction(name ="sendMessage", commitMethod="commit", rollbackMethod ="cancel")
        public boolean sendMessage(final BusinessActionContext businessActionContext,@BusinessActionContextParameter(paramName ="userId")String userId);

        public boolean commit(final BusinessActionContext businessActionContext);

        public boolean cancel(final BusinessActionContext businessActionContext);

    }

How do I pass parameters to the second-phase methods Commit/Cancel?

You can use either of the following methods:

• Use external storage to record the relationship between the transaction ID (txid) and business data.

• Use BusinessActionContext to pass parameters.

  Note

  You cannot pass parameters by directly setting BusinessActionContext. This method does not save the context. You must use the @BusinessActionContextParameter annotation.

If the DTX initiator and participant belong to the same application, can I avoid using RPC?

You can add the @InjvmRemoting annotation to the participant interface. This way, the initiator calls the participant within the same Java Virtual Machine (JVM). In this case, the DTX server does not use the registry to remotely call the second-phase method. Instead, DTX handles the addressing in a closed loop.

Take the TCC pattern as an example:

 // The InjvmRemoting annotation is used when the initiator and participant are in the same application. This means the participant does not need to be addressed by other applications through the registry for RPC calls.
    @InjvmRemoting
    public interface AcctDepositTccService{

        /**
         * <p>
         * Credit accounting interface in TCC pattern.
         * </p>
         *
         * <p>
         * Performs an inflow or outflow operation on the account's funds based on the account's balance direction.
         * </p>
         *
         * @param accountTransRequest The request object parameter. For more information, see {@link AccountTransRequest}.
         * @param businessActionContext The context information of the request in the DTX framework. This is a framework-level parameter that the caller does not need to pass. It is automatically injected by DTX.
         * @return AccountTransResult The transaction processing result.
         */
        @TwoPhaseBusinessAction(name ="creditAction", commitMethod ="commit", rollbackMethod ="rollback", antiSuspend =true)
        public AccountTransResult credit(AccountTransRequest accountTransRequest,@ShardingKeyString accountNo,
                BusinessActionContext businessActionContext);

        /**
         * Second-phase commit.
         *
         * @param businessActionContext The XTS context.
         * @return TwoPhaseResult#isSuccess() Indicates whether the operation is successful. true: successful. false: failed.
         */
        public boolean commit(BusinessActionContext businessActionContext);

        /**
         * Second-phase rollback.
         *
         * @param businessActionContext The XTS context.
         * @return TwoPhaseResult#isSuccess() Indicates whether the operation is successful. true: successful. false: failed.
         */
        public boolean rollback(BusinessActionContext businessActionContext);

    }

DTX reports a "Data too long for column ‘log_Info’" error when creating a transaction branch

Problem

DTX reports the following error when creating a transaction branch: Data too long for column ‘log_Info’.

Cause

The content updated to the database by the business code is too large and exceeds the maximum length of the log_info column.

Solution

Optimize the business code by improving the SQL logic or changing the data type of the column in the table to a type such as LONGBLOB.

The client reports an "invoke dtx-server to create Activity failed" error when starting a distributed transaction

Problem

• The client fails to start DTX and reports the following error: DTX-037: invoke dtx-server to create Activity failed.

• On the DTX server, the actual error code is error code: 101, as shown in the following figure:

• After you convert the character encoding in the console, you can see the actual error: The maximum number of connections to the data source is reached, and no new connections are released within the timeout period. The following figure shows the error:

Cause

The number of database connections between the DTX server and the DTX DB is set to 2.

Solution

If you need assistance, contact technical support.

A "DTX-036 activity record is not exist" error occurs during a transaction

Problem

• The following error is reported: DTX-036 activity record is not exist.

• The following figure shows the detailed error message:

Cause

According to the error message shown in the preceding figure, the instance ID of the transaction requester does not match the instance ID of the transaction participant. For example, the data source ds:jdbc:mysql://10.10.29.212:XXXX is configured with an incorrect instance ID. Its instance ID is set to 00000X, which becomes the transaction requester's instance ID. However, the actual instance ID of the transaction is 8PCDDO6YXXXX.

Solution

Check the application.properties configuration of the transaction participant to ensure that the instance ID of the transaction requester matches the instance ID of the transaction participant.

Does DTX 2.2.1 support the Saga pattern?

No. If you need this feature, contact technical support.

The second-phase request of a distributed transaction is not executed

Symptoms

The following error is reported during use: "com.alipay.dtx.common.exception.DtxException:DTX-032:TCC prepare menthod must have a parameter who's type isBusinessActionContext".

The following error is reported at startup: "DTX-302:initdtx-servers' tcp long-conections failed".

Cause

• The dtxserver did not initiate the second-phase request.

• The client received the second-phase request but failed to execute it.

Solution

The solutions for these two causes are different:

• The dtxserver did not initiate the second-phase request

  Log on to the dtxserver machine. In the /home/admin/logs/dtxserver/dtx-remote.log file, search for the transaction ID to find information about the abnormal transaction.

  • If you cannot find the recovery log for the abnormal transaction, the second-phase task for the transaction has not started. This may be because the task was not executed correctly or a transaction backlog occurred. You must initiate the transaction again.

  • If you find the recovery log for the abnormal transaction, an error occurred during execution. Check the dtx-remote.log and common-error.log files for the cause of the error. After you fix the issue, initiate the task again.

• The client received the second-phase request but failed to execute it

  1. Check whether the client received the second-phase request.

     In the /home/admin/logs/dtx/dtx-rpc.log file on the client, search for the transaction ID. If you find a "BranchCommitRequest" or "BranchrollbackRequest" message, the client has received the second-phase request.

  2. Check whether the second-phase request was executed successfully.

     In the /home/admin/logs/dtx/dtx-rm.log file, search for the transaction ID. If you find content related to "branch commit result" or "branch rollback result" and the returned result is true, the execution was successful. Otherwise, the execution failed. Identify the cause of the failure based on the error message. After you fix the issue, roll back the transaction and execute it again.