-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When the persistent database and business database of cap are not the same database, is there any good way to implement transactions? #970
Comments
This is not a good way. |
Can an API project inject multiple cap services, each of which is assigned a persistent library |
What is the significance of this? |
I have a set of SaaS projects, in which the logic is a set of code, and then through the domain name information during access, I can judge the connection to different customer databases, such as a.com to db-a and c.com to db-c. this function has been realized. |
CAP currently does not support dynamic database switching. |
I currently do this, and then enable the preprocessing transaction in the postgresql configuration, it seems that no bugs will be caused, and the effect is realized. When the final transaction is submitted, the operation transactions of cap and business db will be submitted uniformly, but this requires modification of postgresql. In the configuration file of max_prepared_transactions = 100, the default is 0 to indicate that it is disabled, but it is not clear to open the preprocessing transaction of the database, whether there is any unknown problem |
You only did a successful test. Have you ever done any one step exception and all operations can be rolled back normally? |
https://www.highgo.ca/2020/01/28/understanding-prepared-transactions-and-handling-the-orphans/ |
Close this issue, regarding multi-tenant support, we will have a unified discussion into #699 |
Did you find a workaround? 'TransactionScope' seems to depend on the DTC of Microsoft Windows, which is not supported by linux |
When the persistent database of cap is different from the business database, how should the transaction be handled? According to the following code, the publish information of cap will be inserted into the DB of the business database instead of the DB of cap itself
If you use environment transactions like the following code, you will directly generate bugs in the final commit phase
When the persistent database and business database of cap are not the same database, is there any good way to implement transactions?
The text was updated successfully, but these errors were encountered: