Corey & all others interested in RSB, Today I've been hunting for mysterious distributed transactions appearing out of nowhere in production systems and hanging there forever. And I have made quite unpleasant discoveries along the way. First of all, I learnt that TransactionScope is not as smart as Microsoft says. They say that TransactionScope will not promote the transaction to distributed if there's only one resource manager involved. I thought that if I have one SQL server and only one database I will also be using exactly 1 resource manager, so I will not have distributed transactions when making connections to that database. Wrong! If you open two database connections inside TransactionScope you will be promoted to a distributed transaction! This will happen even if these two connections are identical, the same database, the same connection string (!) Up to today I thought distributed transactions are used when the transaction scope crosses the process boundary (be it on the client or on the server) - but obviously i've been wrong. Now, why I am posting this here - mainly because Corey's work on Service Broker transport will probably not improve performance by not using distributed transactions. Each transaction will be promoted to distributed as soon as you open a second connection to your database. And you almost certainly will open new connection when executing some application logic in a message hander - for example a new ORM session or ADO.Net database update. Also, this is no wonder Ayende had performance problems with MSMQ when executing operations on two queues in a single transaction. Microsoft simply chose to promote the transaction to distributed, no matter if there's only one transactional resource or more.
Next issue: default isolation level with MS distributed transactions is Serializable. This kills last bits of performance remaining after promoting to distributed transaction. Fortunately it can be changed. And more: sometimes distributed transactions will get 'zombified'. They will hang in DTC forever and will not be aborted even after they time out. The problem is that they will hold locks in SQL server, deadlocking with other transactions in the database. I don't know why this happens, googled a bit and found that it can happen when application server dies during a distributed transaction. In our production system the ASP.Net host process is recycled several times a day, so I suspect sometimes a transaction is zombified during such recycle. And this is a 'normal' recycle, not a process crash. If the DTC transaction hangs we have a catastrophic failure reported by our customer (the system throws SQL transaction timeout when executing any action) and the admin has to manually kill dtc transactions. Summing up: Microsoft is certainly abusing distributed transactions. They are slow, execute longer, put more locks on database and reduce system performance. MSDTC is a nasty pig without any useful monitoring/ diagnostic tools. I don't know what's the purpose of building system on top of a message bus when you have to pay such performance penalty. Ah, and please note I didn't perform any tests with RSB - I'm talking about my own message queuing library built on top of SQL server table. But I suspect the problem is also affecting Corey's work. With MSMQ transport it's natural that you will have a distributed transaction so this is not a big surprise. Can you verify if I'm correct? Best regards Rafal On Nov 3, 8:53 pm, Corey Kaylor <[email protected]> wrote: > If you're referring to this > article<http://javiercrespoalvez.com/2009/03/using-sql-service-broker-in-net....>. > 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 -~----------~----~----~----~------~----~------~--~---
