Sorry, I forget to mention the work progressing at Sun on the CachedRowSet
interface. Check it out at
http://developer.java.sun.com/developer/earlyAccess/crs/
jim
----- Original Message -----
From: James Cook <[EMAIL PROTECTED]>
To: A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
Sent: Monday, August 23, 1999 8:43 AM
Subject: Re: Large volume data exchange
> 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".
