Need another case for a Decorator using MediatR and the CommandHandlers (Transactions based on context.Database.BeginTransaction() could be..) about eshoponcontainers HOT 11 CLOSED

I would avoid Transactions via decorators.

We tried this in our early days of running on Brighter, but it leads to the anti-pattern that the whole of the handler is contained within the transaction. Now, if a developer decides to do something long-running here, such as calling an HTTP endpoint, or posting a message onto RMQ, you are going to hold the transaction open for the whole time period. That is obviously a no-no.

For that reason we dropped Transactional decorators and forced developers to explicitly manage the transaction lifetime within the handler.

Our main use case for decorators is resiliency. Brighter wraps Polly and you can then run your pipeline within a Polly policy declaritively. We do this by using a Russian Doll approach to composition. EPoll is a Python library that one of the team wrote that uses a similar decorator wrapper to support resiliency model.

We also use decorators to handle fallback scenarios. Darker, our query side project for example will use it to acces a cache on fallback.

from eshoponcontainers.

Agreed. This issue is actually kind of old and we were thinking about something different instead of a transaction decorator.
The next decorator we were thinking about was a Validator decorator, maybe using FluentValidation https://github.com/JeremySkinner/FluentValidation or similar.

Resiliency might also be a good case for a decorator, although using Polly for resiliency would also be needed from the client apps. We're planning to use Polly for resiliency in the upcoming weeks, as shown in our roadmap.

It would be great to see a fork of this sample app with your implementation using Brighter, so we and the community learn from your experiences. And it would be referenced from our guidance, too. :)

from eshoponcontainers.

Will do, we have 15% time coming up next week, we'll endeavour to get a Brighter fork up and running so you can see how it would work. I can probably get a few co-conspirators to help me :-)

(PS It does also mean we can do some heavy lifting if you need some bodies. Just ask. We have thought about doing something similar to your project, but working with you guys makes more sense, so not a big ask)

from eshoponcontainers.

Sure! If you guys see code that could be improved by itself (not really related to the Brighter implementation), please do pull requests! :)

from eshoponcontainers.

@iancooper , do we have Outbox implementation in Brighton?

Sending message from Command Handler to RabbitMQ might break transactional outbox pattern

from eshoponcontainers.

@maulik-modi Brighter V9 has good Outbox support that works with RMQ publisher confirms. It's in pre-release. I think we need to get another release out in the next day or so for the publisher-confirms code. We'll go to non pre-release once our community have told us then don't have any major issues

from eshoponcontainers.

You choose an Outbox that matches the Db you use, and call DepositPost() within that transaction. You then call ClearoutBox() to flush the messages.

You can then use our OutboxSweeper to look for messages that have not been confirmed as sent within a time window and resend them (you need to run that on a thread yourself, though we are thinking about doing that for you too in a future release).

Both Kafka and RMQ callbacks for confirming a message has propagated to all the nodes are supported and will mark messages as dispatched if they confirm it was sent.

from eshoponcontainers.

There is earlier Outbox support for Brighter, but it was not so simple to use. With this release we have made it easier to use (it's effectively always on but will default to in-memory if you don't configure a persistent store, and we limit how much the in-memory box can grow)

from eshoponcontainers.

@iancooper , Please confirm https://github.com/BrighterCommand/Brighter/tree/master/src is the reository.

When I looked at TopicClientWrapper.cs in Azure Service Bus, I could see Transaction related code, I could not find similar code block in RMQ e.g. https://github.com/BrighterCommand/Brighter/blob/master/src/Paramore.Brighter.MessagingGateway.RMQ/RmqMessagePublisher.cs

public void Send(Microsoft.Azure.ServiceBus.Message message)
        {
            //Azure Service Bus only supports IsolationLevel.Serializable if in a transaction
            if (Transaction.Current != null && Transaction.Current.IsolationLevel != IsolationLevel.Serializable)
            {
                using (new TransactionScope(TransactionScopeOption.Suppress))
                {
                    _topicClient.SendAsync(message).Wait();
                }
            }
            else
            {
                _topicClient.SendAsync(message).Wait();
            }
        }

from eshoponcontainers.

In v9 we use publisher confirms: https://www.rabbitmq.com/confirms.html

https://github.com/BrighterCommand/Brighter/blob/master/src/Paramore.Brighter.MessagingGateway.RMQ/RmqMessageProducer.cs

from eshoponcontainers.

That then hooks back to our Outbox support: https://github.com/BrighterCommand/Brighter/blob/master/src/Paramore.Brighter/CommandProcessor.cs (look at the ConfigurePublisherCallbackMaybe() method to start you off)

from eshoponcontainers.