Multiple database records fetch from browser 2004-02-05 - By VERMA, SANJEEV (SBCSI)
Back
Tim, Thanks for your response.
I guess at this time the requirements are clear enough to start design.
Actually pardon me I didn't want to make the previous mail long enough so
that nobody will read it.
This scenario that I described will happen on the main page of the
application and users may keep looking at the same page for longer time, The
page will just DISPLAY the data, it won't do other operations like
update/insert/delete. There will be many databases so records in different
database will change pretty soon, but we have 0-3 minutes to fetch the
records as per requirement.
As I said there won't be updates on that main page, mostly all the databases
will be updated via different systems/applications.
I guess server push might be a good idea, but I am not sure how it will work
on this scenario.
Thanks
Sanjeev
-- --Original Message-- --
From: Tim Wood [mailto:timwood0@(protected)]
Sent: Thursday, February 05, 2004 1:15 PM
To: J2EE-INTEREST@(protected)
Subject: Re: Multiple database records fetch from browser
At 08:31 AM 02/05/04, VERMA, SANJEEV (SBCSI) wrote:
>Hi All !
>I am facing a situation here where we have to decide which way we should
go,
>either entirely a J2EE approach or J2EE with a small applet on client side.
>I know the client side small applet won't be a good approach.
Well, that settles it then. Thanks for writing. :)
>The problem is our system will talk to multiple databases. On the main page
>we will show data from 4-5 databases. The databases will ALWAYS get updated
>from different systems...
>[ fairly classic cache/replication-control description deleted ]
>Right now in our architecture we are planning to use Struts,Steteless EJBs
>and TopLink. We can go for Entity beans or can tweak the architecture if we
>really have too.
>
>I think there should be some better solution than putting a small applet in
>browser and RMI Server.
I would stop thinking about the point technologies you might or might not
use and consider the requirements of the application. How close does the
user view of the data really need to be to the committed state of the
databases? How often does the database state change materially? What's the
maximum latency & cost of an update to the user display? The answers will
help decide how closely to couple the user view and the database activity.
In general, if you really need close coupling, you will want a persistent
connection to the user's display (browser) and server push of updates. That
lets the update policy and timing be controlled from the server side. This
sounds a lot like a publish-subscribe scenario, but perhaps with stricter
timing requirements. But don't engineer beyond what users need, it's a
waste and will delay the project.
HTH & FWIW,
TW
===========================================================================
To unsubscribe, send email to listserv@(protected) and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to listserv@(protected) and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
|
|
