I too will go with 4th way. But I will give thought of using some sort of
Publisher/subscriber Technology based on JMS. Server will Publish the changed
information and your SWING application will subscribe to the changed messages.
Uday Bhosle
B3Web Solutions
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Uday Bhosle/The Hub Group Inc.)
Subject: updating near-constant data
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.
In the client GUI, you want to present a scrolling list containing the
codes for all airports: "LAX", "SJC", etc. When the user selects "LAX", a
pane containing LAX's name, address, and driving directions is filled out.
The list of airports and associated data is fairly constant, but every few
months an airport might change its name, or the driving directions might
change.
Here are some ways to handle this:
1. Each time the app starts, it retrieves and caches the most current list.
That's 1000 clients times 1Meg of data equals 1Gig of data transfer.
2. Create a session bean with two methods: get a list of all airports'
codes, and get the name/address/directions for an airport given its code.
Fill out the scrolling list with the first method, and when the user
selects a code in the scrolling list, call the second method to get the
airport's specific info. Let's say you have a really, really, slow network,
and these travel agents are really, really impatient.
3. Switch to HTML/Linux/a faster network, "don't worry about 1Gig of data
transfer", "don't put all 3000 airports in a Swing list", etc., etc.
Please humor me on this: let's say that all three of those solutions are
completely impossible.
One other solution is:
4. Keep this 1Meg of fairly constant data on each client. Then, when the
client starts, it connects to the server and asks "has there been a change
to my list of airports since the last time I started?" If the server says
"yes", the client retrieves either the complete list, or any diffs. Or, the
server could send out a notification to the clients saying "there's a new
list of airports available, please contact me for the latest list."
Is solution #4 part of some current or future EJB-related infrastructure or
a known EJB-related pattern? Assuming once again that solutions #1, #2, and
#3 are completely impossible, should I roll my own implementation of
solution #4?
===========================================================================
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".
===========================================================================
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".
