MessageQueue to notify Client of Changes

  • Thread starter Thread starter William Ryan
  • Start date Start date
W

William Ryan

A few months ago (I'm pretty sure it was Bill Vaughn's
article but I can't find it), someone mentioned using
Notification services to tell clients that a change had
been made. I've been working on this for a while, and
I'm convinced it's as doable as it is worth doing. The
implementation wasn't mentioned, but theoretically, it'd
take some work, but I think it wouldn't be prohibitvely
hard to make it happen.

For instance, I could broadcast a message via a trigger
for instance to a MessageQue. My client app could poll
the QUEUE for updates and when one is there, execute a
Refresh. I'm assuming this is on a local network for the
sake of convenience....

A queue seems easiest, but if you had a socket and a
listener, you could poll that for changes, and force a
refresh. This could keep data fresh without pushing
unnecessary refreshes... What do you think?
 
Basically, none of the clients can tell when another one
submitted an update. Data can get stale. Periodic
refreshes keep things fresh , but I'm trying to think of a
way to have the client know a change has been made. A
trigger for instance, or something that could write to a
queue maybe with notification services....when a
Update/Delete/Insert is made, write a 'has changed' notice
to the queue. The client could poll the queue without re-
querying the db, and only if a change was showing, submit
a new refresh query.
 
As I dont know the nature of the application its hard to comment. Is what
you are after a system which notifies the client of which records have
changed and allows the client to refresh optionally, or are you looking to
ensure that the data is as fresh is it can be.

I think either way has its issues. For example if we consider using scenario
2. ( fresh as can be ), then how do you draw the line with refreshes ?, one
record in 500 causes all data to be checked and or refreshed on the client?

I like your idea of using a lisntener on a given socket, with some clever
coding on the server and the client you could make the client update just
the rows which have been changed/deleted or inserted.

If you are talking about a small number of client resident records then
maybe polling refreshes on behalf of the client is more useful. In fact it
might be more beneficial than using a notification system which prompts all
clients to refresh the data at the same time potentially slowing down the
server.

I think in essence, the problem is that ADO.NET isnt really suitable for
real time multi-user environments. This reminds me of the fun we had tring
to make lotus Domino behave like a relational database with record locking,
something its not designed to do.

I dont understand enough about ADO.NET yet to comment with great wisdom,
but this is my simplistic view with what I have discovered so far.


Regards - One Handed Man

Author : Fish .NET & Keep .NET

==============================
 
Back
Top