Peter Cooper wrote: >a) the data stored in the session temp store (my proxy classes) may be >out of date (stale) or otherwise invalid cos another user/session has >changed the persistent data
How is this different from the situation where the session timeout is eight hours (and one user goes out to lunch while another is changing data behind their back)? Just to clarify, the "fix" I tried to describe should behave *exactly* the same, it is *only* the license that should timeout sooner. >b) in complex series of pages making up a single transaction you have >to store all pages and jump back in the middle Same question, I guess. >c) How do you cope with the user opening a new session window >deliberatly - they would not want to reconnect to the existing session Why not? IMHO, the session object should *not* be used for any significant data, only user information. The data regarding transactions etc. should always be stored in the HTML pages (this what I believe is called "page state"). >all in all it's much safer in a data intensive app to re-start >everything otherwise it's simply too hairy Perhaps, but that would be the same for an app with a long session timeout. Again, I only tried to describe a way to handle the licensing problems we discussed, not how to handle other aspects of session timeout and/or session data persistence. Gertjan. -- Gertjan Klein
