-
-
Notifications
You must be signed in to change notification settings - Fork 241
[7.1] Transaction State #412
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
Conversation
Deploying with
|
Latest commit: |
b59ffa6
|
Status: | ✅ Deploy successful! |
Preview URL: | https://13d1a264.laravel-wallet.pages.dev |
Codecov Report
@@ Coverage Diff @@
## master #412 +/- ##
===========================================
Coverage 100.00% 100.00%
- Complexity 320 332 +12
===========================================
Files 54 54
Lines 1117 1145 +28
===========================================
+ Hits 1117 1145 +28
Continue to review full report at Codecov.
|
In vain did the regulator split the service with the state service. It's easy to get new bugs that I brought in with the 7.1.0-RC1 release. I will think about combining services. |
This MR is bold enough for internal optimization. Expect better performance within transactions. |
I would like to add atomicity to the project. Sometimes it is necessary to work with a package within a transaction, and this MR must solve your problem.
Let's take an example. You start the transaction by debiting the wallet money, and then you start to raise an ad in the search. Suddenly your service for working with raising an ad has crashed and it returns any exception. So, the transaction will fail and all operations will be rolled back, but not the storage. If you are using redis, then the balance will already be changed and this must be dealt with.
It turns out that in two databases there is no way to start one transaction. We have to resort to such solutions.
So let's get back to this solution. We create a second store, an array. Inside the transaction, we work with the new storage and, if successful, we update the wallet balance. In case of failure, we delete the data from the temporary storage.
What happens with two running transactions? It's simple, the second storage stores only the difference between the transaction data and the current state of the wallet. If the first transaction completes work faster, then in the second transaction we will work with the current balance.
Let's go back to the example above. We should be able to rollback all changes within a transaction.
Now the transaction also looks at the result from the callback function.