Skip to content
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

Decoration example with DeadlockRetry & Validation #111

Closed
jmzagorski opened this issue May 6, 2020 · 3 comments
Closed

Decoration example with DeadlockRetry & Validation #111

jmzagorski opened this issue May 6, 2020 · 3 comments

Comments

@jmzagorski
Copy link

jmzagorski commented May 6, 2020

In your decoration section you show an example registering a DeadlockRetryCommandHandlerDecorator and ValidationCommandHandlerDecorator. Since the example is simple with no context, that makes sense. However, if your validator accesses the database to validate state, shouldn't the validator run after the dead lock decorator since data may have changed? I realize the docs are just an example. Your docs have great advice for your library and architecture in general so I wanted to make sure I was not missing something.

container.RegisterDecorator(
    typeof(ICommandHandler<>),
    typeof(TransactionCommandHandlerDecorator<>));

container.RegisterDecorator(
    typeof(ICommandHandler<>),
    typeof(DeadlockRetryCommandHandlerDecorator<>));

container.RegisterDecorator(
    typeof(ICommandHandler<>),
    typeof(ValidationCommandHandlerDecorator<>));
@dotnetjunkie
Copy link
Collaborator

Hi Jeremy,

The documentation is indeed meant as a simple starting point. Decorator implementations can become quite advanced and in which order to apply them can depend on a lot of factors. This also holds for whether or not you want to apply the validation inside the transaction or not.

But your point is valid. In case the result of the ValidationCommandHandlerDecorator is dependent on the state of the database, it would certainly be better to apply the validation inside the deadlock retry. When a transaction is rolled back (due to a deadlock), other operations might continue which can change the state of the database and therefore change the outcome of the validations. So that means that rerunning the transaction means it would be better to rerun the validations as well.

But now the question becomes: should the validations run inside the transaction or not? This could be a more difficult question to answer. Running the validations inside the transaction certainly gives the highest degree of certainty, but could, on the other hand, also increase the change of getting deadlocks with a high degree.

But as I said, this is where everything can get quite advanced.

@jmzagorski
Copy link
Author

Great, thanks for that explanation. At the time when I was reading the docs I was taking it as "the way", but as you can tell with my question I started questioning myself during implementation. I always try to look for best practices so I wasn't sure if the docs were taking one stand or the other. However, as you stated it can come down to implementation (most of my implementations involve batch processing in one request so transaction consistency is key and validation is within the transaction, even though that can increase deadlocks. Hearing you talk about it from both sides is great)

I appreciate the response and all the work on this library/docs!

@dotnetjunkie
Copy link
Collaborator

Your question triggered me to update the documentation with a bit more information. Thank you for your question.

Repository owner locked and limited conversation to collaborators May 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants