> Let's say you're writing a Swing-based app to do airline reservations. For
> each of the 3000 or so commercial airports, you need to store the
airport's
> name, code, address, and driving directions. Let's say that adds up to
1Meg
> of data for all airports. And, let's say there are 1000 clients connected
> at any one time.
<snip interesting and probably semi-common problem>
I would go with 4 in any case. Keep a cache on the client, and as you said,
have the session bean on the server implement a method "getAirportInfo(Date
sinceLastCheck)" that returns the list of updated info since
"sinceLastCheck". Have your client do this on upstart and then check at
regular intervals (as I assume these clients are going to be "alive" for a
reasonably long time).
You could also do a little trickery and have a tree of servers which do
caching of data. I.e. the central server keeps the "real" data and then
sub-levels of servers (e.g. one per geographical location that access the
data) update their caches by polling the central server. The clients then
only access a sub-level server, so the strain on the central server is kept
at a minimum. And *then* you can actually have your Swing client get the
whole shebang from the server at startup, since they will be geographically
close to, what they think, is the "data server" (even though theu're only
sublevel caches).
Sounds ok? Introduce more levels of caching servers as necessary. Hardware
is cheap, networks are a bitch.
/Rickard
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
