My concern with this approach is scalability because of the constant
queries that would be occurring in this mode.
...
On the Java side, an AJAX request could be waiting for the server to
respond.
Actually, I think you'd kill scalability more with the approach of
waiting on the dataq. Think about it, web servers are _highly_ optimized
for request processing. A "typical" web page, html, css, .js or two and
a couple dozen images, will result in 30-some odd requests to load. And
they happen nearly instantly. Web servers are not optimized to have a
thread, socket, jdbc connection, etc. held for a long (seconds minutes?
hours?) time.
Just think about the database connection alone. In the polling scenario
you could probably server several dozen polling users with a single
database connection from the connection pool, if not more (depends how
frequently you poll), where in the server push setup you'd tie up a
connection for each requestor.
-Walden
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
-----Original Message-----
From: rpg400-l-bounces+waldenl=techsoftinc.com@xxxxxxxxxxxx
[
mailto:rpg400-l-bounces+waldenl=techsoftinc.com@xxxxxxxxxxxx] On Behalf
Of Paul Holm
Sent: Friday, July 13, 2007 3:28 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Server Initiated Design Alternatives
Hello,
We are building an RFID i5 Java based product where RFID readers
populate DB2/400 files as products pass into and out of "read zones".
We need both a JSP/HTML application and a RPG 5250 equivalent where we
want to continuously see new records/products as they are created and
read without having to manually push a refresh (or F5) button.
Basically the UI should continuously update showing new records. My
question is on design alternatives for both Java/JSP and RPG.
Alternative 1:
I know we could implement a "client" initiated "polling" approach where
the client continuously requests data from the server. From the Java
side I could use AJAX requests in a loop and from RPG use loop to reread
or check a data queue.
My concern with this approach is scalability because of the constant
queries that would be occurring in this mode.
Alternative 2: (Server to client push)
Anyone have experience or recommendations with a server to client design
approach? I'm hoping to not use sockets based server to client because
of the complexities and firewall/port issues.
I'm thinking an approach where a database operation would result in a
triggered data queue entry that could be "waited on". Once a data queue
entry is read, RPG could update its display. On the Java side, an AJAX
request could be waiting for the server to respond.
Advice, experience, or insight is appreciated before we go off on this
task.
Thanks, Paul Holm
midrange.com
