title: Should I use MSMQ or SQL Service Broker for transactions?
body: <p>I've been asked by my team leader to investigate MSMQ as an option for the new version of our product. We use SQL Service Broker in our current version. I've done my fair share of experimentation and Googling to find which product is better for my needs, but I thought I'd ask the best site I know for programming answers.</p>
  
  <p>Some details:</p>
  
  <ul>
  <li>Our client is .NET 1.1 and 2.0 code; this is where the message will be sent from.</li>
  <li>The target in a SQL Server 2005 instance. All messages end up being database updates or inserts.</li>
  <li>We will send several updates that must be treated as a transaction.</li>
  <li>We have to have perfect message recoverability; no messages can be lost. </li>
  <li>We have to be asynchronous and able to accept messages even when the target SQL server is down.</li>
  <li>Developing our own queuing solution isn't an option; we're a small team. </li>
  </ul>
  
  <p>Things I've discovered so far:</p>
  
  <ul>
  <li>Both MSMQ and SQL Service Broker can do the job.</li>
  <li>It appears that service broker is faster for transactional messages.</li>
  <li>Service Broker requires a SQL server running somewhere, whereas MSMQ needs any configured Windows machine running somewhere.</li>
  <li>MSMQ appears to be better/faster/easier to set up/run in clusters.</li>
  </ul>
  
  <p>Am I missing something? Is there a clear winner here? Any thoughts, experiences, or links would be valued. Thank you!</p>
  
  <p>EDIT: We ended up sticking with service broker because we have a custom DB framework used in some of our client code (we handle transactions better). That code captured SQL for transactions, but not . The client code was also all version 1.1 of .NET, so we'd have to upgrade all the client code. Thanks for your help!</p>