Chris,
I think you might want to test your assumption that a network operation is too
slow for your purpose. We also have a swing based GUI for editimg complicated
domain objects. The data is retrieved in a lazy fashion. This generally means
that all the data for a given form (page, screen, etc...) is obtained in a
single ejb method. Data for additional related forms or pages are retrieved when
that form is shown. We find that the server response time is very fast. The
speed problems we have are mostly related to swing. Building and initializing
the UI is a memory hog and rather slow. And since swing isn't thread safe, you
have to be careful about doing things in parallel threads. Lots of stuff ends up
getting posted to the awt dispatch thread.
Between the database cache, the app server bean caching and the persistence
engine caching data, operations like switching back and forth between to
transactions takes several milliseconds. We also use session beans for this kind
of use case which keeps important client state on the server. For dependent
lists, as in your second example, dynamic queries are built by the session bean
and executed faster than swing can redisplay the list. For bulk operations,
stateless session beans work well. Since our entity beans load related
collections and referenced objects only when needed, it's possible to do many
bulk operations using entity beans without taxing the DB. Where that isn't
feasible, we go directly to the database. Our client code never accesses the DB
or entity beans directly.
I originally had many of the same concerns you do, but have found over time that
they were largely unwarrented. So my point is test your assumptions, you might
be surprised.
--Victor
Chris Kelly wrote:
> For instance, let's say the auditor flips back and forth between a
> transaction that occurred in January and another transaction that occurred
> in December. The auditor doesn't want a network operation to take place
> each time they click on a transaction for more information. So, all of the
> data must be on the client.
>
> And, let's say that the GUI is very complicated. The contents of JList A
> depends on whether JCheckBox B is checked, and which item is selected in
> JList A determines the list which is shown in JList B, etc. etc. We don't
> want a network operation to occur everytime the user selects an item in
> JList A.
>
> Also, let's say sometimes the auditors access the network over the
> internet, and sometimes over a LAN. To make matters even more complicated,
> let's say another machine (connected over the internet) wants to do bulk
> operations on AccountHistorys. Like, get 100 AccountHistorys at one time,
> look for certain patterns, and perhaps edit those AccountHistorys.
>
===========================================================================
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".
