If you're referring to this article<http://javiercrespoalvez.com/2009/03/using-sql-service-broker-in-net.html>. Yes I've read it although I don't agree. It really depends on what is important to you. The comment about poison messages in the article is valid. However, I have prevented that by never rolling back the dequeue call. If it fails I resend the same message back to the transport endpoint. The consume method is called within its own isolated transactionscope preventing a failure rollback for the dequeue as well. The comments in the article about distributed transactions aren't valid either because my implementation will support it if it requires a promotion to DTC, but in most cases won't need it. The comments in the article about not all resources are sql server resources might be valid, but for myself it holds true for 99% of our resources and I don't mind catering to that 99%.
Regardless of the frustrations you might have with RSB, it has been a great thing for us and if it wasn't so nicely designed and extensible I wouldn't have even attempted to do this in the first place. The nice thing about open source software is where you feel things are lacking or not perfect for your scenario you can contribute to make it better, or tweak it and make it work for your needs. It's not hiding it's located here<http://github.com/CoreyKaylor/rhino-esb/tree/servicebroker>. I may blog about it and our successes with RSB in the next few weeks. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
