Decoration example with DeadlockRetry & Validation

[jmzagorski]

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]

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]

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]

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