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?
Other related information
6条答案
按热度按时间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.
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.
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.
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?
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.
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.