This is a perennial problem when developing applications in a distributed
environment. No matter what underlying mechanism is used to stream the data
(RMI, IIOP, Raw, etc.), a few thousand records will cause a noticeable
drain.
The obvious solution is the one that is not so easy to implement. You need
to figure out a way to send as little of the information as necessary to the
client. For example, if the data is in the form of a grid, the user can only
see on page of data at a time. This may be 30 or less records. By sending 50
records before and after the current record, the user may be able to
experience reasonable scrolling behavior. It would also be good to pre-read
the first 100 and last 100 records to allow quick jumping to the beginning
and end of the grid.
Of course this mechanism can get very complicated, very quickly. The current
JTable is well-suited to support such a design given it's separation of data
from GUI, but it isn't going to be too easy. For best effect, a client-side
*and* server-side model would be best. The client-side model would cache
data. It could even be multi-threaded to allow the retrieval of information.
The cursor support in JDBC 2.0 could help conserve server-side resources,
but when all is done, you may want to read all of the records into some
TableModel on the server.
There should be a mechanism in place for this type of streaming data source.
I don't know of any. The Inprise Data Express architecture may offer some
clues on how to do this. It would be nice if some technique that is
EJB/Session Bean-based could be offered to the world. It would seem to be
very well suited for the server piece. We need it for JList, JTable, JTree
and any other Swing component that can potentially display large amounts of
data.
jim
----- Original Message -----
From: Gabby Tal <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 23, 1999 7:57 AM
Subject: Large volume data exchange
> Hi,
>
> We're designing N-tier application where the clients are desktop Java
> application.
> The issue we're about to deal with is that the client has to retrieve a
> large volume of data
> (lets say a few thousands of DB entries) generated by the EJB server as
> a response to some request.
> The questions are how is it recommended to exchange such volume of data
> considering the fact that the client should display this information in
> Swing table (enabling) high degree of data manipulation (as opposed to
> HTML based client).
> Should be a problem moving such large volume via RMI?
> and if so, is it reasonable to manage it in application level (for
> example saving the result in the client's associated session bean and
> then transferring it chunk by chuck to the client).
> What about using XML as a solution?
>
> Any help would be highly appreciated.
>
> Gabby
>
>
===========================================================================
> 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".
