Persisting a Dataset

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,
I have a Windows Forms app deployed on Terminal Server. When the app
starts, it loads up several datatables that then serve as the datasource for
comboboxes throughout the app. One of these datatables has about 5000 ROWS,
at 2 columns each. I would like to avoid having each user's instance of my
app load such a large datatable into memory. Any suggestions on how I can
load a globally common instance of this data, that can be used by each
instance of my app?
 
I'm not sure you're going to get around the memory issue without possibly
using cross-appdomain remoting because Terminal Server will create separate
app domains for each exe that is running. Also, the DataTable would have to
be read-only because I don't see how you could update the table in a
threadsafe manner through databinding. This is an interesting issue I may
have to play with. One approach could be to create a separate library with
a remotable Singleton class (inherits MarshalByRefObject) and is thread safe
which would load the table into memory and serve all the exes. I'm not sure
how the databinding would behave though. You may end up having to serialize
the DataTable across the appdomain anyways and that would defeat the
purpose.

How many TS sessions are you running? How much memory is that DataTable
actually using? You may have an easier time breaking down the amount of data
you load into the table. Does the user really need all that data available
at once? Is there a way you can fetch the data only if it is needed? If you
can store the table to disk and load it into memory only when needed, that
may be an easier solution.
 
Thanks Beth. The datatable occupies about 400KB. It is read only, and is
needed by each user. The application is for entering medical claims and the
datatable contains a list of possible medical diagnosis codes. I would like
to get at least 50, and hopefully 100, users on one box with 2x2.7 Xeons and
4GB RAM.
Thanks
JT
 
Ahh.. ok, ICD9 codes? :-). (I work for a medical software company too <g>)

Since we have about 18000 codes to deal with in our product we have a
searching mechanism instead. The user can either enter the code manually
into a textbox and save the form (where it is then validated by the server
components and saved to the database), or they can click a button to execute
a search. The search will only pull down rows that match the code (or
description) that they entered so usually you're only dealing with a few
rows. We then cache all the searches to disk so that if the same search is
executed again, then the server component/database is not bothered, instead
we just ReadXML from disk into the search results table. Now our winform
clients are distributed across the network not on a TS so each cache is
stored on the client computer in the user's local settings folder. However,
I believe that with a TS setup you could actually do the same thing because
(correct me if I'm wrong) the user's log in and run the exe under their
security context and have local settings folders. If cache the data to disk
and provide a search instead, then you won't have to load all the rows into
memory. However, it seems like the bulk of your memory would be taken up
with loading the exe (user interface) itself. If you can break your exe up
into separate assemblies so that they are not loaded until the user accesses
a section of the application then you will also save memory if parts of the
application are only used by some people or not very often. Also you may
want to check out putting some assemblies into the global assembly cache. In
that case all exe's would share the same assemblies.

You can find some performance measuring and tuning tips here:
http://msdn.microsoft.com/library/en-us/dnpag/html/scalenetchapt15.asp

HTH,
-B
 
You've got dual 2.7 megaherz processors, 4 gigibytes of ram and you're
worried about 400 kilobytes per user (4 megabytes maximum) - less than 1% of
the RAM resource?

On that sort of box I would consider a datatable of that size to be tiny
even when scaled up to 100 or so Terminal Services users.
 
Silly, huh? Thanks for the reality check. Also, thank you Beth for your
very helpful replies.
JT
 
Back
Top