Updating a table view as a database information changes.

Me and a group for class are implementing a three tier system with an interface that involves a table, and remote procedure calls to update and view recent information. We are using MySQL and java to do it. I have already learned how to connect and query the database and use it to do all the table modifications on the user end side to update the database.

What I am wondering though is, if one of my interface applications has a table, how would I implement a way to keep the table information consistent if another application updates that same information. Do I just constantly refresh the information by comparing a last modified timestamp or something? The thing is since it's three-tier the interface is not necessarily synched with the database directly, but goes through a controller in the app logic to connect to the database. Does the other application also have to share the same service that the first app uses to modify the update and just send the information that it was updated to that app? I know the observer pattern applies (Subject being the database connection class, and observers being the two interfaces), but implementing it through sockets I don't really get.

I think MySQL's triggers don't yet support signalling another application, so you have two options.
One, you poll the database in regular intervals.
Two, you implement the system so that every client that modifies the database sends out a notification. You could use e.g. a message broker system for that. Or, if there really is only one controller that does all the database accesses, you can do internal notifications there, and you only need to make the client application capable of receiving the notifications.
If they're thick clients, that should be no problem at all. If they're web clients, it typically comes back to polling.

well the controller acts as a service provider, spawing service threads providing connections to the database, the service is linked via a socket back to the client and it sends it's remote procedure calls that way. The thing is, once that thread is spawned, I have no way to call it's native methods even with a reference, since it's seen as a thread rather than the class I'm implementing.

I'm assuming by thick you mean a desktop app, both of them are, but since I'm working with threads, polling seems to be the way to go.

Quote:

---

The thing is, once that thread is spawned, I have no way to call it's native methods even with a reference, since it's seen as a thread rather than the class I'm implementing.

---

Huh? You mean, you have a java.lang.Thread reference, so you can't call it's methods? How hard would it be to retain an additional reference to the interface ModificationListener? Especially since the whole event listener thing is already implemented in the standard library?

Polling is bad. It should always be a last resort only.

Actually the class implements the runnable, not extend the Thread class.

You think I can just use a callback?

I don't see why not, as long as your remember the multi-threading issues.

ok, I'll see if I can make up a sample project to work it out. Thanks for the input.