> The data I was going to keep in memory on the server was > "Catalog" data...data that doesn't change much at all if any. I'm > thinking we will be better served to store this info on the client > machine, reading directly from the DB when the app starts under a worker > thread.
Can't you do that anyway? Keep your current solution, but fetch the catalog on the worker thread so the rest of the application looks like it is running. Make a proxy for the "cache" so if it currently doesn't contain the data for some query it makes a database hit instead. You can also setup a modification log so the clients get an empty catalog cache to start and slowly fill it up from the mods-log from the server... then as time goes on, the mods-log keeps the clients up-to-date. You can get as simple as just storing a modification sequence number (INT IDENTITY) a table identifier, and the primary key of the modified record... then give the server a service that takes the client's last-known update pointer (or zero for give me everything), and then you just stream 100 rows (or so) at a time back to the client... he saves the data locally and loops back for more. Do this on a worker thread and you can catch up a cache in almost no time. We did much the same for a thick-client, distributed application called Sendouts. It worked fine even over modem lines. -- "Under capitalism, man exploits man. Under communism, it's just the opposite." –John Kenneth Gailbraith Marc C. Brooks mailto:[EMAIL PROTECTED] http://musingmarc.blogspot.com
