March 8, 2012 at 12:46 am
Comments posted to this topic are about the item Scaling Out
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
March 8, 2012 at 5:05 am
I think that Service Broker is a great tool! At my last employer, we implemented it to do asychronous processing in the background. It is not very difficult to learn and implement, but, there are some nuances. Like you said, however, not many people are using it, so support in forums like these is not abundant, although folks like Remus, the author of the article to which you linked and one of the developers of Service Broker, are great once you get in touch with them! That lack of widespread popularity in use may be discouraging to folks trying to implement it. Like you, I would encourage others to investigate it...they may be surprised at its potential use.
Thanks...Chris
March 8, 2012 at 6:50 am
I've implemented a service broker architecture for an application. The biggest problem with Service Broker is the fact that any error in Service Broker is severity 16 and causes transactions to instantly become either uncomittable or fail outright. For something designed to be a background service, MS needs to modify it with respect to transactions so that you can either continue after an error, or rollback to a checkpoint and keep going. The exceptioning in Service Broker is, imho, the single biggest reason that it has been ignored because it's not longer a background item, but a foreground pass/fail operation.
March 8, 2012 at 6:59 am
agreed, great technology. Am about to use this on a new project. It seems to involve a totally new way of looking at the problem. Not always intuitive to add work to a queue and process later but worth the overhead when you cant control workload.
Am curious to see what 2012 brings
March 8, 2012 at 10:05 am
Hope: "However I thought over the next 3-4 years it would catch on as we companies looked to scale out their databases to multiple physical servers."
Reality: "It has a steep learning curve, the tools have not advanced very far, and the documentation and descriptions can be confusing and incomplete."
Great article and good observations about Service Broker. However, you kind of answered your own question or hopes for Service Broker. Also, I would add there are alot of moving pieces that can break and stop the whole process as well mentioned in a previous post. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
March 8, 2012 at 11:49 am
I have the same general approach to Service Broker that I have to DTS, and I do to SSIS: I try to use more standard tools more of the time, and less standard tools less of the time, when the various tools have functionality that overlaps.
I try to avoid DTS; much of what I saw it used for could be done just as well in straight SQL with the Agent scheduling, and it went away with no real upgrade path beyond "rewrite in something different".
I try to avoid SSIS: see DTS.
The same thing applies to Service Broker; if there is another reasonable way of doing the work that's less dependent on a Microsoft-specific tool set, I'll use that. Straight SQL is at least loosely tied to the ANSI standard. Yes, I'll use SQL Server specific techniques, but the bulk of the code can actually be "ported" to another database or version when required, rather than needing to be re-implemented from the design, or perhaps even re-designed from the requirements.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply