Service Broker
What can be the Benefits of Programming with Service Broker?
In which condition one should use Service Broker?
Do you have Sample link for Code/Video that easily/precisely explains it's usage?
Queuing and asynchronous messaging are needed for many database
applications today. Service Broker provides a new, queue-based durable
messaging framework to address these needs. Using the Transact-SQL API
provided by Service Broker, you can easily develop services to handle
application requirements for queuing or asynchronous communications.
Some of the benefits of programming with Service Broker are:
Flexible development: The programs used in a single distributed
application can be written in multiple languages. Each program
provides the functionality of each distributed application component.
Improved security: You can express security requirements via
certificates, so application components do not need to share the same
security context. Service Broker uses SQL Server security features to
help you secure your applications.
Transactional processing: Message processing occurs within SQL Server
transactions to ensure data integrity. Service Broker supports remote
transactional messaging over a standard connection to the database.
Guaranteed ordering: Service Broker provides strong guarantees
regarding the delivery and processing of a related set of messages
exactly once and in order, so no additional coding is required to
provide this functionality.
Reliable delivery: All of the data needed for a conversation--a set of
related communications between two or more services--is persisted in
SQL Server. Service Broker supports clustering and database mirroring.
A conversation may be maintained through system restarts, server
failover, network outages, and so on without failing or losing data.
Improved scalability: Service Broker routing delivers messages based
on the name of the service, rather than on the network address of the
computer where the service runs. This allows you to install an
application on multiple computers without changing application code.
Ability to leverage existing knowledge: Service Broker uses
Transact-SQL to create objects. Applications that use Service Broker
are most often implemented in Transact-SQL or Microsoft .NET
Framework-compatible languages. You do not have to learn a new
language to create Service Broker applications.
For further detail check this link
http://dotnet.dzone.com/articles/c-sqldependency-monitoring
Service brokers are useful when we want do asynchronous processing in the database. which will improve the performance.
When we need inter database communication.
you can find sample code for creating and sending the messages using service broker here.
Related
In SQL Server, What is enable_broker?
What is the risk?
SQL Table Dependency wants that.
1) https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/sql-server-service-broker?view=sql-server-2017
SQL Server Service Broker provides native support for messaging and
queuing applications in the SQL Server Database Engine. This makes it
easier for developers to create sophisticated applications that use
the Database Engine components to communicate between disparate
databases. Developers can use Service Broker to easily build
distributed and reliable applications.
2) https://www.sqlservercentral.com/Forums/Topic818423-146-1.aspx
One risk being if there are already service brokers setup to use that
DB they will probably break, and any live connections will be killed
and rollback.
3) Sql Dependency with Service Broker
It's not necessary but if you want to see changes you need it or you can use an other service like periodic polling
Be careful using the SqlDependency class to monitor changes in the
database tables - it has the problems with the memory leaks.
I hope it will help you !
My first ever question on stack overflow so please go easy. I have a long running windows application that continually processes sql server commands. I also have a web front end that users use occasionally use to update the same db. I've noticed that sometimes (depending on what the windows application is processing at the time) that if a user submits something to the db I receive out of memory exceptions on the server. I realise I need to dig around a bit more and optimise the code. However I cannot afford the server to go down and expect that in the future i'll be allowing more and more users on the frontend. What i really need is a system that will queue the users requests (they are not time critical) and process them when the db is ready.
I'm using SQL 2012 express.
Is SQL Service Broker the best solution, i've also looked into MSMQ.
If so can someone point me in the right direction for it would be appreciate. In my search i'm just finding a lot of things it does that i don't think i need.
Cheers
It depends on where you're doing the persistence work, and / or calculations. If you're doing the hard work in your Windows Application, then using a Service Broker queue won't be worthwhile, as all you will be doing is receiving a message from the Service Broker queue in your Windows Application, doing your calculations and / or queries from the Windows Application, and then persisting the results to the database: as your database is already under memory pressure, this seems like an unnecessary extra load as you could just as easily queue and retrieve the message from MSMQ (or any other queueing technology).
If however you are doing all the work in the database and your Windows Application just acts as a marshalling service - eg taking the request and palming it off to a stored procedure for actioning - then Service Broker Queues may be worth using: because they are already operating within the context of the database, they can be very efficient at persisting amd querying data.
You would also want to take into failure modes, depending on whether or not you can afford to lose any messages. To ensure message persistence in MSMQ you have to use Transactional Messaging: Service Broker is more efficient at transactional queue processing than MSMQ (because it has transaction support built in, unlike MSMQ which has to use DTC, which adds an overhead) - but if your volume of messages is low, this may not be an issue.
I'm in need of an Enterprise Service Bus/Message Queueing solution for publisher/subscriber functionality. I know MANY exist... MSMQ, MS Series, RabbitMQ, NServiceBus, etc etc etc...
My one requirement is that in a shared hosting solution, the only dependency that I can guarantee will exist is SQL 2005 and later... this leads me directly to SQL Service Broker.
If it sounds like I'm trying to shoehorn ESB functionality into SSB... I suppose I am...
My question is: does anyone know of a .NET API or framework that sits on top of SQL Service Broker and already provides much of the plumbing?
If I were to use pure ADO.net, I could add items to the queues by calling a stored procedure, but then:
Do to the nature of conversations, would I make one conversation per message?
If so, do I lose sequential message processing?
How do I receive messages (I know the receive syntax in t-SQL), do I call a stored procedure repeatedly in a message loop to try to
get a message off the queue?
Or would I WAITFORever? Keeping the connection open and executing the stored procedure forever?
SQL Service Broker doesn't support monologue conversations, but I read they can be implemented...
It's these kind of questions that make me wish there existed a .net solution that already managed all of this.
There was an effort to package a WCF Transport Channel for SQL Server Service Broker but, afaik, is abandonware.
But NServiceBus supports Service Broker as a transport, see Using NServiceBus and ServiceBroker.net and there are github projects like A simple wrapper API for SQL Service Broker and an ITransport plugin for NServiceBus. While not exactly mainstream, some support and community effort does exists.
As an ESB I think you will have problems due to lack of true pub-sub and broadcast. SQL Server 2012 has the ability to SEND a message to multiple targets, see How to Multicast messages with SQL Server Service Broker, but you will still have to implement the pub-sub infrastructure (publishing topics, subscribers etc) from scratch. MySpace did that and was a major effort, see Scale out SQL Server by using Reliable Messaging. My observation reffers to the low level direct use of SSB, I have never used NServiceBus so I cannot tell how well does it abstracts/expose unicast/broadcast/multicast/pub-sub over SSB.
As for your specific questions, I recommend reading Writing Service Broker Procedures and Reusing Conversations.
Recently my clients have asked me if they can use they’re application remotely, disconnected from the local network and the company server.
One solution is to place the database in the cloud, but a connection to the database, and the cloud and an internet connection must be always available.
There not always the case.
So my question is - Is there any database sync system, or a synchronization library so that I can work disconnected with local database and when I connect synchronize the changes I have made and receive changes others have made?
Update:
The application is under Windows (7/xp) ( for now )
It's in Delphi 2007 win32
All client need to have Read/Write access
All Clients have internet connection, but not always ON
Security is not critical, but the Sync service should encrypt the communication
When in the presence of the companies network the system should sync and use the Server Database and not the local one.
You have a host of issues with thinking about such a solution. First, there are lots of possible solutions, such as:
Using database replication within a database, to mimic every update (like a "hot" backup)
Building an application to copy the database periodically (every night)
Using a third-party tool (which is what you are asking, I think)
With replication services, the connection does not have to always be up. Changes to the database are logged when the connection is not available and then applied when they can be sent.
However, there are lots of other issues when you leave a corporate network. What about security of the data and access rights? Do you have other options, such as making it easier to access the database from within the network? Do the users need only read-access to the database or read-write access? Would both versions need to be accessed at the same time. Would there be updates to both at the same time?
You may have other options that are more secure than just moving a database to the cloud.
I believe RemObjects DataAbstract allows offline mode and synchronization by using what they call Briefcases. All your other requirements (security, encrypted connections, etc.) are also covered.
This is not a drop-in replacement, thought, and may need extensive rewrite/refactoring of your application. There are lots of upsides, thought; business rules can/should be enforced on the server (real security), scriptable business rules, multiplatform architecture, etc.
There are some products available in the Java world (SymmetricDS lgpl license) - apart from actually being a working system it is documents how it achieved synchronization. Connects to any db with jdbc support. . There is a pro version but the user guide (downloadable pdf) gives you the db schema plus rules on push pull syncing. Useful if you want to build your own.
Btw there is a data replication so tag that would help.
One possibility that is free is the Microsoft Sync Framework: http://msdn.microsoft.com/en-us/sync/bb736753.aspx
It may be possible for you to use it, but you would need to provid some more detail about your application and operating environment to be sure.
IS it possible to share a database like .mdb and work fine? i try but sometimes the file where the databse is changes from DB to DB1 i use delphi Xe4 and Google Drive .
Thank´s
I'm learning about MSMQ and am successfully using it to queue email and text messages from a consumer-facing ASP.NET MVC website, to be handled by a separate client application.
In the event of a missing SQL Server database, perhaps while swapping drives or a broken database deploy, would it make sense to queue non time-critical inserts in a local MSMQ queue to improve up-time?
Theoretically, I can then pause/resume queue processing (persistence) while making database changes. Has anyone tried this or is there a better way?
If you're looking at higher availability by queueing locally then you should consider Service Broker deployed on SQL Express instances collocated with your IIS/ASP instance. The advantage of using SSB over MSMQ is that you have consistency between your message store and your data store (one consistent backup/restore, one consistent failover unit), it does scale much better than MSMQ under load, it does not require tw-phase-commit DTC to coordinate the MSMQ dequeue with the DB insert (can use one local DB transaction to dequeue/insert), it offers queryability of the pending messages (SELECT .. FROM queue), is integrated with the DB HA/DR solution (cluster failover/mirroring), you get DB contained activation and it all works from the familiar T-SQL programming environment. MSMQ's main advantage is support of a client side C#/.Net API.
I was on a team that implemented this for purposes of guaranteed delivery. We used MSMQ to forward the insert requests to the database server, which had its own service running that dequeued the requests and ran the inserts, then acknowledged the message (to ensure delivery). It's been running for over a year now, and we've never been asked to come figure out why it isn't working...seems pretty solid to me.
This is very subjective because it depends on what your application does and how. Generally, something like MSMQ is not used for this purpose, rather you want to set up some kind of high-availability clustering on your database of choice. The occurrence of a database going completely down is rare in most cases, and generally a bigger problem for most LOB applications than just having somewhere to store data entered while the DB is down for whatever reason.
There's also overhead to think about. An INSERT operation to a database is relatively quick (in the larger scheme of things); writing a serialized something into a queue and having something pick it up and do that insert operation is going to add large amounts of lag to your application, not to mention the fact that you'll have to account for the fact that now everything is asynchronous.
That said, MSMQ can be used to ensure delivery of stuff from one end of an application to another, so I suppose there are instances where this scenario might be desirable. Most of the time though you're just better off trusting your DB and using MSMQ to enable asynchronous processing and performing interprocess and intermachine communication.