Wouter Oet wrote:Since you posted in Beginning Java: could you give us your definition of realtime? (I've heard several very different ones).
I too, noticed that people misuse the term "realtime" to mean commercial applications. Or applications written by professional programmers. This is not true, as realtime has a very specific meaning.
Realtime is a term for applications that has very specific SLA requirements for response time. In Java, it could be doing lots of stuff to simulate it; or using the realtime JVM.... but quite frankly, and many will disagree with me, more realtime applications are simply not done with Java.
Do you mean you want the application in one client to refresh its view of the database when another client sends data to the database?
You can achieve this in two ways. Either you can have your viewer poll the server every now and then to see if there was an update, or your server can keep track of who is interested in changes, and send them a message about a change.
You have to be more clear in what you want though.
Stephen is talking about the publisher/subscriber design pattern. In a nutshell, each client application registers with the server that it wants to know about whatever changes.
Suppose your application displays weather, stock reports and news headlines (and say 30 other things). The user can configure it to only display certain parts. The client application would tell the server "I care about weather and stock reports". So, the server would only send that client weather and stock updates, but not news headlines.
Alternatively, you could write is so that your client asks the server for the weather and stock updates every 30 seconds, but not the stock reports (assuming that is how the user has it configured).
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Stephan van Hulst wrote:You have to be more clear in what you want though.
Agreed. I would suggest you are approaching this backwards. Normally when you design an application you should first identify what you want to do, and second figure out how you are going to do that.
But in your case it seems you have decided in advance on how you are going to do it, or at least you have some vague idea how you are going to do it, you just don't know what you are going to do. And I suggest that isn't a good way to design an application.
But perhaps this is some kind of homework assignment, where you are supposed to write something which illustrates some particular feature of a language or some particular type of design pattern? If so it might be better if you just told us what the assignment was, instead of providing a brief and inaccurate summary of it.