Increased chance of running into concurrency related issues when using MSMQ transport

[timbussmann]

Describe the bug

Description

When using the TransactionalSession with MSMQ transport version 1.x, there is a significantly increased chance of running into concurrency-related problems (see next sections for more details).

This is not in itself a bug in the TransactionSession but caused by a bug in the MSMQ transport: Particular/NServiceBus.Transport.Msmq#621. This issue is only created to help document the symptoms as it's most likely that the MSMQ bug is observed when using the transactional session.

Expected behavior

The transactional session dispatches the internally used control message and uses custom delayed retries (not managed via the user-facing delayed retries configuration) to absorb possible and expected race conditions as documented here.

Actual behavior

Due to the delayed retries not working in this case, the tombstone might be created too quickly which can increase the risk of running into concurrency-related problems. This would typically manifest in database-specific errors either thrown from transactionalSession.Commit() or logged as immediate retries. The log might contain statements like these when using NHibernate persistence:

NHibernate.Exceptions.GenericADOException: could not insert: [NServiceBus.Outbox.NHibernate.OutboxRecord][SQL: INSERT INTO nsb.OutboxRecord (MessageId, Dispatched, DispatchedAt, TransportOperations) VALUES (?, ?, ?, ?); select SCOPE_IDENTITY()] ---> System.Data.SqlClient.SqlException: Violation of UNIQUE KEY constraint 'UQ__OutboxRe__C87C0C9D85B42523'. Cannot insert duplicate key in object 'nsb.OutboxRecord'.

Versions

This affects only usages of the transactional session with MSMQ transport version 1.x

Steps to reproduce

See Particular/NServiceBus.Transport.Msmq#621

Relevant log output

No response

Additional Information

No response