CODEWITHSUNDEEP
nservicebussqlconnectionsqlcommand
endyourif
endyourif

Reputation: 2202

NServicebus handler with custom sqlconnection

I have an NServiceBus handler that creates a new sql connection and new sql command.

However, the command that is executed is not being committed to the database until after the whole process is finished.

It's like there is a hidden sql transaction in the handler itself.

I moved my code into a custom console application without nservicebus and the sql command executed and saved immediately. Unlike in nservicebus where it doesn't save until the end of the handler.

Upvotes: 1

Views: 328

Answers (4)

Ramon Smits
Ramon Smits

Reputation: 2618

Unit of work

Messages should be processed as a single unit of work. Either everything succeeds or fails.

If you want to have multiple units of work executed then

  • create multiple endpoints
  • or send multiple messages

This also has the benefit that these can potentially be processed in parallel.

Please note, that creating multiple handlers WILL NOT have this effect. All handlers on the same endpoint will be part of the same unit of work thus transaction.

Immediate dispatch

If you really want to send a specific message when the sending of the message must not be part of the unit of work then you can immediately send it like this:

using (new TransactionScope(TransactionScopeOption.Suppress))
{
    var myMessage = new MyMessage();
    bus.Send(myMessage);
}

This is valid for V5, for other versions its best to look at the documentation:

http://docs.particular.net/nservicebus/messaging/send-a-message#dispatching-a-message-immediately

Enlist=false

This is a workaround that MUST NOT be used to circumvent a specific transactional configuration as is explained very well by Tomasz.

This can result in data corruption because the same messsage can be processed multiple times in case of error recovery while then the same database action will be performed again.

Upvotes: 1

Tomek Masternak
Tomek Masternak

Reputation: 86

As mentioned by @wlabaj Setting Enlist=False will indeed make sure that a transaction opened in the handler will be different from transaction used by the transport to receive/send messages.

It is however important to note that it changes the message processing semantics. By default, when DTC is used, receive/send and any transactional operations inside a handler will be commited/rolled-back atomically. With Enlist=False it's not the case so it's possible that there will be more than one handler transaction being committed for the same message. Consider following scenario as a sample case when it can happen:

  • message is received (transport transaction gets started)
  • message is successfully processed inside the handler (handler transaction committed successfully)
  • transport transaction fails and message is moved back to the input queue
  • message is received second time
  • message is successfully processed inside the handler
  • ...

The behavior with Enlist-False setting is something that might a be desirable behavior in your case. That being said I think it's worth clarifying what are the consequences in terms of message processing semantics.

Upvotes: 0

wlabaj
wlabaj

Reputation: 468

Indeed every handler is wrapped in a transaction, the default transaction guarantee is relying on DTC. That is intentional :)

If you disable it then you might get duplicate messages or lose some data, so that must be done carefully. You can disable transactions using endpoint configuration API instead of using options in connection string.

Here you can find more information about configuration and available guarantees http://docs.particular.net/nservicebus/transports/transactions.

Upvotes: 2

endyourif
endyourif

Reputation: 2202

Found the solution.

In my connection string I had to add Enlist=False

Upvotes: 0

Related Questions