-
Notifications
You must be signed in to change notification settings - Fork 31
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
Add an option to forbid active transactions in specific methods (@nestjs-cls/transactional) #166
Comments
This is already supported, please refer to the Transaction propagation section of the docs. You're probably interested in the |
At first I thought
If I understand this correctly, the transaction is still active even if we don't use it. Active transactions that take too long to finish can cause deadlocks.
This will throw an error if there's an active transaction, which is what I want, but if there are no active transactions this will create a new one. I'd like to have a guarantee that there are no active transactions at all. |
Hm, you're right, there currently isn't a propagation mode that satisfies your scenario. I'll have a look how the Spring framework handles it (the current set of propagation modes is straight up copied over from their implementation) so I'm not reinventing the wheel. If I don't find a satisfying answer, I'd propose a new mode What do you think? Currently, if you want to implement such functionality in the userland, you can check if a transaction is currently active by calling |
Well I guess it depends if you want to call this a type of "transaction propagation", because it's not really about propagation. That's why I proposed a new decorator, it just seems like a separate thing from propagation. But hey, maybe I'm just nitpicking and |
I don't feel particularly eager to adding a completely new decorator for this single use case and widening the library's API surface. But you're right that it's not exactly about propagation and I was also hesitant to call it that. On the other hand, it also is kind of related to propagation. Maybe we just need to find a more fitting name. I mean, to be completely honest, the names of the other modes are not exactly descriptive either :D I just didn't want to diverge from an established naming "Transaction propagation to this method is not allowed" doesn't feel that off to me after all. Or maybe "forbidden", "rejected"? |
I'm casting my vote to "rejected". My favourite so far. |
It turns out that I probably misinterpreted the The fix is simple, this line should be changed to But at the same time, I can't imagine a scenario where one needs to use the |
In the end I decided that the original behavior of From now on, the Released in |
I'd like to mark some parts of my application as "transaction free", because they can take some time and they shouldn't have an active transaction while running. For example, if I'm communicating with external APIs with a transaction open that can cause DB deadlocks if the external API takes too long.
If I could mark those methods with something like
@ForbidTransaction
I could make sure that there are no active transactions. The decorator could throw an error if the method is called with an active transaction.The text was updated successfully, but these errors were encountered: