Hi, I am looking for some suggestions to a Java application that we are trying to architect. Here's the problem:
1. Users on a browser client will fill up a few "search" critieria and hit search.
2. The search request flows through the web/app server to the database, retrieves the records and brings it back to the client.
3. The records in the database can be dynamically updated by another program (these are stock quotes which can change in real-time).
4. We would like to update on the client, only those rows which correspond to the records that have actually updated in the database.
How do we PUSH these deltas to the client? Also, how do we know which user is looking at which record that has to be updated by a PUSH? The "PULL" solution, where every few seconds, we run the search query to the database, does not sound good because it will be a performance hog. Performance is a very important thing here.
How do we handle the situation where a new record has been dynamically added to the database and this record matches the user's search criteria?
Has anyone solved a similar problem? Any suggestions? Is this even possible with a browser client?
Thanks a lot.
Deltas are not possible with a browser. All a push enabled browser understands is "multipart/x-mixed-replace", meaning the browser keeps the connection to the server and each new part pushed by the server replaces the previous one upon receipt.
The current servlet spec does not address server push. Although anything is possible if you try hard enough,I wouldn't implement push using servlets or JSPs. First you have to keep the client connection for time indefinite and then you have to send the servlet to sleep till a change occurs. When it wakes up it will run the query and push the new part before going to sleep again. It just doesn't sound right for a servlet.
Another (producer/publisher) program dynamically updating the database, which your (consumer/subscriber) application constantly "listens" to, seems a very bad idea. You cannot establish a performing publish-subscribe model via a database, maybe you should give some thought to making the two applications communicate.
Tracking brand new data will require lots of care and work and will be frustrating no matter what approach you choose. The simple case of reissuing every active query upon receiving new data is a bad idea, performance wise. Trying to determine which queries may be affected is a hard task and will require you to analyze (and interpret) users queries. The risk of some user not getting the new data in time because the app chose not to reissue his query will sink in and you will have more and more lax rules and more and more reissued queries with no new results.
Who said life was easy?
I would say, the server push solution is a dead end in your situation. The only way it'd fit your case, would be if you implement every row in a table as a separate frame or frame-like entity, and have multiple server pushes into these frames. Horror. If you think client pull solution was resource-intensive, wait and implement the server-push solution, and you'll think that client pull was not that bad after all :)
A java applet might be a good solution (or, maybe, DHTML code, even though this would make it married to IE browser).
It might connect (via URLConnection facility) to java servlets (via http) to check for new information. Alternatively (if firewalls are not an issue), you could write your own simple server and protocol handler and have this applet maintain a continuous connection to a socket on your server, feeding from it and updating its table rows as necessary. This would eliminate any delay.
Two questions to be solved:
1) is java applet GUI (AWT, not Swing!) adequate for display of your table rows ?
2) are firewalls an issue ? (and how to deal with them if so)