Supplement to the Seata official documentation and extension of global transaction rollback strategies

oewdyzsn  于 3个月前  发布在  其他
关注(0)|答案(6)|浏览(52)

Why you need it?

In this official documentation, I think it's essential to provide the specific path to the documentation and the explicit configuration file. When local transactions outside the global transaction have manipulated some data, leading to inconsistencies between the snapshot information and the current data when the global transaction rolls back, what strategy has Seata implemented? What is the default logic and configuration? Alternatively, if Seata's inherent logic cannot meet user requirements, is there an available interface to pass context information and snapshot data, enabling users to customize certain rollback actions?

yeotifhr

yeotifhr1#

This kind of problem positioning and maintenance is quite difficult for me personally. If there are many custom scenarios, using TCC might be more suitable.

lh80um4z

lh80um4z2#

This kind of problem positioning and maintenance is quite difficult for me personally. If there are many custom scenarios, using TCC might be more suitable.

Sure, but I recommend first completing the official documentation here. As for whether the AT mode should offer an interface to customize the rollback of global transaction snapshots, I believe this can be discussed by relevant individuals in the community.

xvw2m8pv

xvw2m8pv3#

AT mode is the automatic mode. When faced with inconsistent issues that cannot be handled, it adopts a "fail fast" strategy. This aspect is not directly supported in the SDK for direct expansion. Transaction revision control can be done in the console in the future.

6pp0gazn

6pp0gazn4#

#4585
#4559
We have 2 solutions in mind for now, I wonder what you think about these two solutions? Or do you think it's better to have custom extensions?

w9apscun

w9apscun5#

I have read these two questions and understood their meanings. Currently, I think both solutions are feasible. It's possible to skip some field checks through configuration, after all, not all fields need to undergo snapshot comparison, which offers more flexibility in selection. I also think it's necessary to extend the interface. In some more complex logic scenarios, it may be necessary to query the current business data through snapshot data and metadata information, compare the data weight, and then make the correct rollback logic. I think both of these conditions are necessary to cater to different scenarios.

7ajki6be

7ajki6be6#

Upon further reflection

From the point of view of the current AT mode, considering AT mode is an entirely automated management mechanism for global transactions, it should emphasize its automated aspect more. The primary issues occur when users do not correctly configure annotations for global transaction management, or when they set up scheduled tasks or execute timed scripts in the database, leading to mechanisms outside of the global transaction altering some field information in the snapshot data within the current global transaction.

Following this line of thought, field filtering configuration could potentially be the primary mechanism to resolve these issues, and it could narrow down the data management of global transactions to the field level. This could reduce unexpected inconsistencies in snapshot data for certain fields. Although it cannot completely solve the root problem, it can ensure that the issue arises in the expected fields.

Contrarily, asking users to implement their own rollback logic seems to require more than just the logic for a single table. They might need to implement logic for all related business tables involved in the global transaction. This could indeed impose a significant mental burden on users. Moreover, such implementation is similar to TCC's implementation logic and doesn't quite align with AT's design philosophy. It might be a solution of last resort.

相关问题