You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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: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
The text was updated successfully, but these errors were encountered: