I have a SQL server and couple Windows clients and cache of some tables as objects on clients. I currently have a pull mechanism where every one minute or so clients query one row in DB to understand if cache is still good if changed they sync everything, but I want to change this mechanism to push based. I mean I want server to “ping” clients in the event of an update. On server side I assume I can use triggers but on client side what do I need to implement?
Query Notifications is the only mechanism for SQL to push to client a change notification. The client side is best known as the SqlDependency. See http://rusanu.com/2006/06/17/the-mysterious-notification/
Related
One way communication, from app to db is well apparent. Is there a way that my db also communicate back to app/ middle tier, or multiple instances of middle tier or apps.
Can triggers be used for this purpose in conventional rdbms (sql server/postgres)?
If you have a .NET based application, you can get notification back from SQL Server easily.
SQL Server service broker infrastructure, query notifications enables notification from database back to the application.
You can implement this in 3 ways.
1- Using SqlNotificationRequest class. Example
2- Using SqlDependency. Example
3- Using SqlCacheDependency Example
We are using Sql 2012 database server. When ever the db modifies we want it to trigger a message that can be stored in a queue using activemq.
We are not sure how can we code to trigger a db so that it sends a message.
Can we directly make the message generated from db to get queued in activemq without any java interface in between. I would want to know whether we can achieve this or not.
3.Are there any other ways to set up a communication between sql server and activemq say between database services and activemq services(does activemq have that)
PS i am a new user of activemq. Any leads to solve these queries is appreciated.
Please don't as SQL Server to do this. SQL Server is designed to store data. You are asking too much of it. Depending on how many places you would want to add to this queue from, I would choose one of the following solutions:
If you want to add to this queue from a bunch of different places, and don't want to change existing code, create an application to move items from SQL Server to ActiveMQ. The items in SQL Server can be populated by a trigger.
If there are only a few places that add to this queue, add that logic to the application so that every write to SQL Server will also write to ActiveMQ.
If you really still don't want to modify any code, you can configure ActiveMQ to use SQL Server as its persistence database. Then you can modify its data and hope that it plays nice. This is definitely not preferable. I would rather put CLR code into SQL Server to push data to ActiveMQ.
I've been wondering what are the advantages/disadvantages of storing session data on the API server. It seems a bit more intuitive to store session data on the API server, but I could see benefits of keeping the API stateless and using access tokens to access data.
What are your thoughts?
Thanks!
Matt
I would say, it is good to store session in a server other than application server and API server.
Because of speed, memcached and Redis is used as session storages. They are fast because they are memory-based.
For scaling-out, I recommend you to separate session storage from API and Application server.
Even if you had problem in application and API server for certain period of time, sessions would not be lost in that case.
From what I've read so far, neither.
There's another similar question that asks whether, in a true REST-style setup, the Application Server or the Database Server should hold the sessions. Several people responded that, while it's sometimes faster or more convenient to keep on the application server (or in your case the API server), it's preferable to store sessions in a database or Memcache.
If you keep them on the API Server, you run the risk of losing the sessions if the server crashes.
Also, (I paraphrase from AJ) keeping your sessions on the API server will only work if:
Your clients always connect to the same server (aka "session affinity")
Your server nodes all use a common mount point to spool sessions
I'm not sure the second one applies as much in this situation, but the database and/or Memcache (Thanks InspiredJW) idea does sound your best bet!
Thanks much
I'm developing application WinForms .net 4.0 using C# and the backend is SQL Server 2008
the nature of the data for this app is to be displayed to the user in real time manner, whenever the data is changed or new data was added the UI has to reflect that in real time.
I'm trying to find out the best way to get the data from SQL without constantly pooling from the server, I came to a few options:
Create background thread to update the data. (I don't like pooling from the server)
Use SQLDependency class to receive notification from the server.
What do you recommend, or if you have a better method it will be great if you can share it.
If you only have a few clients then a SQLDependency *might be an OK solution. However here is the Microsoft recommended approach for a full blown client/server application.
http://msdn.microsoft.com/en-us/library/ms187528.aspx
This approach is good for many clients but less frequent changes.
The last time I had this type of requirement for more frequent changes with a bunch of clients (i.e. thousands) we built a middleware service that we installed on the server which in turn broadcast the running changes from the database via socket.
I have a WCF service that needs to notify it's clients when changes occur to the database (sql server 2005). This is relatively easy accomplished, as long as I find a way to notify my service of any changes. I can probably create a database trigger on a table and have that trigger start a small service client that notifies my service, but I'm wondering if there's a better way to do this? It would be a viable solution to have the service poll the database for changes, but I'm not sure on the best way to do it (and sendign a notification to my service would be preferred).
As the relevant updates apply only to a certain part of the database, I was also wondering if it's also possible to link such a trigger (or other mechanism) to a database diagram.
All help is appreciated!
rinze
If your database is SQL Server 2005 and above you can try this solution: Remove pooling for data changes from a WCF front end.
As a side note, never call external processes from a trigger, don't make web calls from a trigger. Is a guaranteed recipe for disaster.
Update
For those interested in mixing Query Notifications with LINQ to SQL I recommend Using SQLDependency objects with LINQ.
Look at
SQL Server 2005 Query Notifications Tell .NET 2.0 Apps When Critical Data Changes
Change Notification with Sql Server 2008