Unlocking the Potential of Service Broker in SQL Server 2005
Discover the power of Service Broker, a new technology in SQL Server 2005 that enables asynchronous messaging, deferred processing, and scalable fault-tolerant queue processing. Learn when to consider using Service Broker for long-running processes, event-driven architectures, and efficient data-intensive queuing operations without continuous polling. Explore how Service Broker can alleviate the burden on overburdened database servers and complement existing ESB/EMS solutions.
Uploaded on | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
What is Service Broker? New technology in SQL Server 2005 async messaging Deferred processing Queue Processing (unordered and FIFO) nothing new to install or license, just enable it
When should we consider using SB? Long running processes...fire and forget! loosely coupled, asynch processes that SCALE fault tolerance scale-out (distributed) possibilities automatic eventing (a stored proc fires async when a message is enqueued)
When should we consider using SB? respond to events without continuous polling (push queue) Query Notifications (data caching) (pull queue) data-intensive queuing operations cheap, efficient transactions (no 2PC) anytime we want to push our messaging support burden onto the DBAs
Isn't "database as a queue" an anti- pattern? Usually yes developers can't design and code queueing systems without having lock, block, and deadlock problems. SB solves this. Think about PrcsStsCd and pull queues ...Too much polling ...SQL Server is efficient at CRUD or SELECTs, but rarely both ...not enough queue draining ...too tempting to put shared state in the db queue, causing tight coupling
Isn't the db already the big bottleneck? Yes, but this technology can alleviate our overburdened db servers by processing data smarter.
But we already have ESB/EMS! Service Broker is complementary It is not a JMS replacement use it for all of the reasons mentioned already
