MSMQ как очередь заданий

Использование MSMQ в качестве хранилища данных, вероятно, плохо, поскольку оно вообще не предназначено для хранения. Если очереди не являются транзакционными, сообщения могут даже не записываться на диск.

Конечно, обновление элементов очереди на месте не поддерживается по указанным вами причинам.

Если вам не нужна полноценная реляционная БД, вы можете использовать какой-либо кеш в памяти, например memcached или дешевый объект db, такой как raven.

Взгляните на RabbitMQ или многие другие очереди сообщений. Большинство предлагают эту функциональность из коробки.

Например. RabbitMQ называет то, что вы описываете, рабочими очередями. Несколько потребителей могут извлекать из одной и той же очереди и не извлекать один и тот же элемент. Кроме того, если вы используете подтверждения и обработка завершается сбоем, элемент не удаляется из очереди.

Примеры .net: https://www.rabbitmq.com/tutorials/tutorial-two-dotnet.html

РЕДАКТИРОВАТЬ: Насколько я могу судить, после использования MSMQ, это, вероятно, очень хорошо сработает для того, что вы делаете. Ключевым моментом является использование транзакций и нескольких очередей. Например, у каждого статуса должна быть своя очередь. Достаточно безопасно «перемещать» сообщения из одной очереди в другую, поскольку это происходит внутри транзакции. Это перемещение сообщений по сути является изменением вашего статуса.

Мы также используем массив байтов Message Extension для хранения метаданных сообщения, таких как статус. Таким образом, нам не нужно изменять фактическое сообщение при перемещении его в другую очередь.

MSMQ и очереди в целом требуют набора шаблонов, отличного от того, к которому привыкло большинство программистов. Запомни.

Возможно, если бы вы могли предоставить больше информации о том, почему вам нужно просматривать сообщения, которые в данный момент обрабатываются, можно было бы справиться с этим сценарием с помощью MSMQ. Вы всегда можете добавить базу данных для дополнительного отслеживания.