views:

311

answers:

6

What is the best way to program an immediate reaction to an update to data in a database?

The simplest method I could think of offhand is a thread that checks the database for a particular change to some data and continually waits to check it again for some predefined length of time. This solution seems to be wasteful and suboptimal to me, so I was wondering if there is a better way.

I figure there must be some way, after all, a web application like gmail seems to be able to update my inbox almost immediately after a new email was sent to me. Surely my client isn't continually checking for updates all the time. I think the way they do this is with AJAX, but how AJAX can behave like a remote function call I don't know. I'd be curious to know how gmail does this, but what I'd most like to know is how to do this in the general case with a database.

Edit: Please note I want to immediately react to the update in the client code, not in the database itself, so as far as I know triggers can't do this. Basically I want the USER to get a notification or have his screen updated once the change in the database has been made.

A: 

Triggers?

brian
I want to immediately react to the update in the client code, not in the database itself.
Daniel
Then you'll need some mechanism for the DB to "talk back" to your client. A trigger in the DB is likely the only way to immediately detect changes in the DB.
sleske
Did you read the question?
Geoffrey Chetwood
+1  A: 

Well, the best way is a database trigger. Depends on the ability of your DBMS, which you haven't specified, to support them.

Re your edit: The way applications like Gmail do it is, in fact, with AJAX polling. Install the Tamper Data Firefox extension to see it in action. The trick there is to keep your polling query blindingly fast in the "no news" case.

chaos
Please see my edit above, as far as I know triggers can't do what I'm asking for.
Daniel
Re your edit: This seems crazy to me because gmail has tons of clients, to have all of them polling the server all the time seems so inefficient. There's got to be a better way... But thanks for that insight, I wouldn't have thought that's how it's actually done.
Daniel
The alternative, "server push", the Big New Thing That Will Revolutionize The Web of 1994 or so, involves keeping a live TCP connection for every client, which is an exponentially worse idea.
chaos
I remember the Netscape FishCam that used server push circa 1994. Very exciting.
Chris Farmer
A: 

The Observer Pattern

brian
How would I implement this with an off the shelf RDBMS like MS-SQL?
Daniel
The observer pattern makes sense but how would the observer (client) know about the events coming from the database without checking for them all the time? This pattern seems like it's for a self-contained program.
Daniel
+6  A: 

I figure there must be some way, after all, web application like gmail seem to update my inbox almost immediately after a new email was sent to me. Surely my client isn't continually checking for updates all the time. I think the way they do this is with AJAX, but how AJAX can behave like a remote function call I don't know. I'd be curious to know how gmail does this, but what I'd most like to know is how to do this in the general case with a database.

Take a peek with wireshark sometime... there's some google traffic going on there quite regularly, it appears.

Depending on your DB, triggers might help. An app I wrote relies on triggers but I use a polling mechanism to actually 'know' that something has changed. Unless you can communicate the change out of the DB, some polling mechanism is necessary, I would say.

Just my two cents.

itsmatt
+1  A: 

Unfortunately there's no way to push data to a web browser - you can only ever send data as a response to a request - that's just the way HTTP works.

AJAX is what you want to use though: calling a web service once a second isn't excessive, provided you design the web service to ensure it receives a small amount of data, sends a small amount back, and can run very quickly to generate that response.

teedyay
What about for normal desktop applications with a database back-end. Is there a way to push data to the application from the database? Maybe some type of connection that stays open?
Daniel
Not actually true. Server push does work. It's just a colossally bad idea.
chaos
Thanks chaos - I wasn't aware of that. I guess because it's such a bad idea, I've never even heard of it! :-)
teedyay
+6  A: 

You basically have two issues here:

  1. You want a browser to be able to receive asynchronous events from the web application server without polling in a tight loop.

  2. You want the web application to be able to receive asynchronous events from the database without polling in a tight loop.

For Problem #1

See these wikipedia links for the type of techniques I think you are looking for:

EDIT: 19 Mar 2009 - Just came across ReverseHTTP which might be of interest for Problem #1.

For Problem #2

The solution is going to be specific to which database you are using and probably the database driver your server uses too. For instance, with PostgreSQL you would use LISTEN and NOTIFY. (And at the risk of being down-voted, you'd probably use database triggers to call the NOTIFY command upon changes to the table's data.)

Another possible way to do this is if the database has an interface to create stored procedures or triggers that link to a dynamic library (i.e., a DLL or .so file). Then you could write the server signalling code in C or whatever.

On the same theme, some databases allow you to write stored procedures in languages such as Java, Ruby, Python and others. You might be able to use one of these (instead of something that compiles to a machine code DLL like C does) for the signalling mechanism.

Hope that gives you enough ideas to get started.

Evan
This is precisely what I was looking for. Thanks!
Daniel
I don't know why but server push is rarely utilized well.
Faiz