|
Greg didn't really like my previous example and says that one could easily pass the SqlTransaction to a method, thereby eliminating the need for implicit distributed transactions:
The benefit, obviously, is not having to use distributed transactions, and the associated overhead that comes with them. In my opinion, the code above is not complicated, and other than the boilerplate code, the "way of thinking" is much the same as it is with using declarative transactions with EnterpriseServices. And to come back to Ingo's point, I think if all of your business methods are designed like this, you can add/remove them at will from the call chain, and everything should still work.
Definitely true - at the first look. But what happens, if you later decide that you need distributed TX, probably because another method wants to integrate the addition of a new customer with a post to a message queue? This wouldn't be possible using the code you've shown. (And I'm not even talking about what happens if some method somewhere deep down the call chains screws up the transaction logic by preliminary committing a TX).
On the other hand, your point regarding the overhead of distributed TX is well understood. Wouldn't it be great if EnterpriseServices would allow for transactions to start as local ones and later be turned into distributed TX "on demand" - as soon as you access a secondary resource manager? In fact, this feature is planned for the future and the only reason I didn't talk about it before was that I thought it was NDA information. I was wrong - it is already in public and can be found at http://www.gotdotnet.com/team/xmlentsvcs/esfaq.aspx#5.2 (next to some other great information about this topic).
In the future, Enterprise Services will support the concept of promotable transactions which will begin as a local transaction and will be promoted to a distributed transaction when required.
Pretty cool, huh? Hearing about this feature was definitely part in triggering my love for this technology.
|