New Posts New Posts RSS Feed: Server-side change notification
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Server-side change notification
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
midnit View Drop Down
Senior Member
Senior Member
Avatar

Joined: 22-Jun-2009
Location: Charlotte
Posts: 112 		Post Options Post Options   Quote midnit Quote  Post ReplyReply Direct Link To This Post Topic: Server-side change notification
    Posted: 04-Jan-2012 at 11:27am
We would like to notify client apps when table data has changed so they can requery and stay fresh. Unfortunately triggering this from the database has problems which we cannot overcome so I am looking to fall back on at least notifying if data was changed through our application. I was considering doing this via an EntityServerSaveInterceptor but was hoping for a little guidance if there was a better alternative.
 
I would like to identify that items have been changed and push that information to clients and if the clients care about those types they could query to get the new info. Currently my experiment is using the MessageQueue to queue the items, and each client subscribes to the push when it connects and at an interval it pushes the info to the client which has a subscribe mechanism for the modules so when something that it cares about changes the modules do what they need to.
 
I would love some other thoughts/ideas or suggestions of a better route.
 
Our clients are Silverlight.
Back to Top
WardBell View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Mar-2009
Location: Emeryville, CA,
Posts: 338 		Post Options Post Options   Quote WardBell Quote  Post ReplyReply Direct Link To This Post Posted: 04-Jan-2012 at 7:37pm
Big topic for which there is no one correct answer. I'll try to give a schematic answer ... one that leans toward "it depends" but provides some meat.
 
DevForce supports both polling and push approaches. You can read about push here: http://drc.ideablade.com/xwiki/bin/view/Documentation/push-notification . Or you could use some kind of message bus (NServiceBus or something in Azure maybe); this last approach would be out-of-band from a DevForce perspective.
 
They all have one thing in common: you must write server-side code that determines what has changed and when it changed ... in a way that is useful to clients. I think this is what you are asking about.
 
Again, the solution depends upon business and application specifics that I only you know. You could put the detection logic in the EntityServerSaveInterceptor because there you can know when a DevForce client application is saving changes. Of course you will miss changes made to the database is some other way. If that is a risk, you can write and run a daemon process on the server that watches for database changes of interest.
 
Whatever you do about detecting changes, you then must decide where and how to record them. Some people use message queues. Those who want to stay in the database paradigm will log consolidated change entries in a "Change" table.
 
Having figured that out, you now have to decide how to communicate those changes to the clients that care. Such clients could poll the Change table using standard DevForce. That's the easiest approach because you don't have to worry about pub/sub; each client manages its own needs.
 
Or you could resort to some kind of server-side process push that sends change notifications to subscribing clients either by using the DevForce push facilities mentioned above or with a message bus (an alternate push mechanism outside of DevForce).
 
Should you push or poll? There is no right answer. Everything depends upon your actual scaling and timing requirements.
 
Polling is the easiest way and is just fine for many applications. I know people who reject polling as a matter of principle without regard to any of the tradeoffs. That attitude is costly and naive. Server-side push adds complexity that is not repaid until the number of users is quite large or the latency requirement is especially brief (sub-second).
 
Maybe you've done the math and you know that you have to push (you have hundreds/thousands of interested clients and/or subsecond latency SLAs). Then you can look into DevForce push ... and look into a message bus ... and decide which way works for you. Both will be more challenging than polling ... but if that's what you need ... then you do it.
 
Whatever you decide, make sure that you (1) wrap your solution in abstractions that free you to change your implementation later and (b) measure performance results against your requirements.
 
Hope that helps.
 
 
 


Edited by WardBell - 04-Jan-2012 at 7:38pm
Back to Top
midnit View Drop Down
Senior Member
Senior Member
Avatar

Joined: 22-Jun-2009
Location: Charlotte
Posts: 112 		Post Options Post Options   Quote midnit Quote  Post ReplyReply Direct Link To This Post Posted: 09-Jan-2012 at 10:32am
Thank you for the response. It was helpful in mirroring some of my own thoughts and verifying there wasn't a piece of DevForce I was overlooking.
 
The current experiment has the database logging data changes to a table, the application server polls the table and pushes relevant information to the clients and the clients requery what they care about.
 
So far the performance is fantastic and close enough to real-time that our users are happy and with a single instance of the server polling I feel more comfortable with the traffic involved.
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down