Enhancing Transaction Handling for TimeoutRollbacked and Rollbacked States

[YongGoose]

The current transaction processing logic in Seata is well-structured and efficient. However, handling transactions in the TimeoutRollbacked and Rollbacked states can be further improved to enhance stability and efficiency.

Releated Issue

• TimeoutRollbacked and Rollbacked residues #6875

📌 Proposal: Enhanced Transaction Processing

To address these issues, I propose the following improvements

1️⃣ Transaction Queue Introduction

• Both committed and rolled-back transactions will be added to a queue for more efficient state-based processing.

2️⃣ Enhanced Scheduler Functionality

• The scheduler will retrieve transactions from the queue and direct them to the appropriate processor based on their state.

3️⃣ Improved Rollback Processor

• A dedicated rollback processor will handle rolled-back transactions.
• Successful rollbacks will be reported to the monitoring system.
• Failed rollbacks will be sent to a retry queue for future reprocessing.

Sequence diagram

With this approach, we can effectively mitigate issues related to TimeoutRollbacked and Rollbacked transaction states, improving overall transaction management stability.

Looking forward to feedback and discussion on this proposal! 🚀

I haven't been studying the Seata project for long yet.
If there are any mistakes or areas where my understanding is lacking, I would greatly appreciate any feedback. 🙇🏻‍♂️

[funky-eyes]

I understand that your design is to quickly trigger compensation for failed events by adding monitoring events for transaction end status results. But one thing needs to be made clear. The failure of transactions in the end status is most likely due to network and disk problems. Your compensation behavior may still fail within a certain time frame. And in your design, the process looks like a memory queue? In Seata's storage mode, only file and raft transaction data are in memory, while db and redis are external storage. So I think it may be more appropriate to compensate by timing tasks and delaying tasks.

[YongGoose]

Your compensation behavior may still fail within a certain time frame.

I hadn't thought about that part, thank you :)

So I think it may be more appropriate to compensate by timing tasks and delaying tasks.

I agree with that suggestion.

So, instead of creating a separate scheduled task to handle rollback and commit states for all transactions as mentioned in the comment below, would it be sufficient to process only the failed transactions in the end?

Since both of these probabilities are very low, the final result is that they are both deleted. If you think it is necessary to handle rollbacked transactions during runtime, I suggest that you create a separate scheduled task to batch process transactions in the rollbacked and committed states, rather than blocking transactions that urgently need to be rolled back and retried.

PS. Would it be possible to ask for a more detailed design?

I previously wrote a post on the mailing list to propose a solution for a different issue, and I think the methods mentioned there might also be worth considering in this discussion.

• https://lists.apache.org/thread/xlkshkqs5v2hflp10jgz418kos8vwrsc

[funky-eyes]

    private final GlobalStatus[] endStatuses = new GlobalStatus[] {GlobalStatus.Committed, GlobalStatus.Rollbacked};

Build a scheduled task for transactions in the 'end' state. You can refer to handleRollbackingByScheduled and handleCommittingByScheduled, but their final handling logic only needs to call SessionHelper.endRollbacked or SessionHelper.endCommitted

[YongGoose]

Hasn’t SessionHelper.endCommitted already been included in this PR?

• feature: Implement scheduled handling for end status transaction #7133

If it’s not just calling SessionHelper.endRollback immediately but calling it after a certain period of time, I think it would be a good idea to use a separate thread to create a scheduled task.

code snippet example :

public static void scheduleEndTransactions() {
    scheduler.scheduleAtFixedRate(() -> {
        try {
            Collection<GlobalSession> endSessions = getEndSessions();

            for (GlobalSession session : endSessions) {
                if (session.getStatus() == GlobalStatus.Committed) {
                    SessionHelper.endCommitted(session, false);
                } else if (session.getStatus() == GlobalStatus.Rollbacked) {
                    SessionHelper.endRollbacked(session, false);
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }, 0, 1, TimeUnit.MINUTES);
}

If that’s not the case, I’d love to know what additional work I need to do.

I really want to contribute to Seata’s transaction management logic, but since I’m still not very familiar with the project, it’s a bit challenging. 😅

[funky-eyes]

I believe this code is already 80% complete, and the remaining work is to refine some details.
Since the business thread process involves changing the globalsession status to "end" and then performing the deletion, there will be a concurrency issue between this asynchronous thread and the Seata-server's business thread. Therefore, there is a timeToDeadSession method in the globalsession. When its return value is less than or equal to 0, we can assume that the transaction needs to be compensated. Of course, this timeToDeadSession method is more relevant for ongoing statuses like "rollbacking" or "committing." For transactions in the "end" status, I believe the interval can be shortened. This way, it is possible to handle transactions in the "end" state in a thread-safe manner without using locks.

[YongGoose]

Thank you for your response! 🙇🏻‍♂️
I will analyze the DefaultCoordinator code and apply it in the appropriate place.