VOLKAN ÖZÇELİK wrote: > That is to say, to reduce the server load, we designed a fat client. > Is is ta relevant approach. What are its pros and cons? Probably discussed in enough other places; I go back and forth on my own projects. A lot of it depends on the location -- that is, the available bandwidth -- of the clients. <snipped questions about MS-only clients -- no comment :-) /> > And finally, will large session timeouts (say 3 hours per sesion) lead > a significant performance degredation? (our users will be entering > large texts, while making phone calls, examining papers etc... Being > idle for an hour and losing everything they have written in a textbox > upon session timeout will be a nightmare for them. > > i. Shall we implement a timeout counter which alerts user something > like "your session will be expired in 10 minutes if you don't save > your work" ? With as little as you say you're storing in session, I can't see that having *no* session timeout would even be a problem from a performance perspective, especially if the users are likely to be doing other things and hence have prolonged inactive periods. You don't say how much memory you're allocating to the container's JVM, or if you're using a particular GC scheme, but those are both things you can fine-tune as you go. There are lots of monitoring options. Given the description of the app, have you considered just doing a periodic save? Snag the contents of that textbox they're working on every 10 minutes and write to a temporary table or whatever? Why even make the user worry about it if you're already running a fat client with async communication back to the server? FWIW! -- Hassan Schroeder ----------------------------- hassan at webtuitive.com Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code.