4 ms·
nice, but this line var receiveOperation = queue.StartReceiving<MyMessage>(100, /* poll every 100 ms */ shows that you are polling the queue for new messages.
by lafar6502 13y ago
nice, but this line
var receiveOperation = queue.StartReceiving<MyMessage>(100, /* poll every 100 ms */
shows that you are polling the queue for new messages. Why such inefficient technique?
And BTW it looks like there's no support for transactional operations. This is indeed a rudimentary queue ;)
- aashishkoirala 13y agoWhat it does there is call the WCF service to see if there is a new message. If there is, it will consume it and call again. The wait only comes into play if there are no messages. In terms of why I am polling, without going into duplex communication, I could not find a purely event-driven/subscription-based way to do this. I mean, I could use a queue- but then a queue that uses another queue to do its thing would be somewhat absurd.
- aashishkoirala 13y agoAlso, there is somewhat of a support for transactional operations - you can declare a queue as transactional - which will return the message to the queue if the client fails. However, there is no concept of poison queue - or integration with TransactionScope.
- Pxtl 13y agoI'm curious, have you ever got distributed transactions - particularly ones over WCF and the like - working? I've found that wile TransactionScope works like a dream in the trivial case, it becomes disproportionately hairy and frustrating as you start trying to use such elaborate features.
- aashishkoirala 13y agoIt generally works with anything that supports MSDTC; multiple SQL Server nodes being the most usual scenario. The one case where it starts to get hairy is when you bring MSMQ into the mix, not surprisingly. That has been my experience, anyway.