Wednesday, March 20, 2002 08:50 AM
I think the idea, the reason that the form bean is in the session rather than the request scope, is that a user may be interacting with the same form more than once, across multiple requests, in the same session.
Also a form bean can be used for the data of more than one form page, i.e. in a set of related forms, in a workflow or whatever, which would each come in their own request.
Disclaimer: Maybe someone else has already thought of this and has already implemented it and sells it, or has it for open source downloading somewhere..... but if not, hey give me some credit in your notes when you do it, :-)
It does sound like you have brought up something important, in design and support for scaleable Web applications, that perhaps where needed, control of server-side data (cached persistence) and expiration ought to be more fine-grained than just the choice of which scope to assign it to (the request, session, or application), and having it live or die equally with everything else in the chosen scope.
I could imagine a session manager servlet, for instance, which could read policy config files, or could be sent hint messages, and which would monitor the session scope state, maybe even in the (memory, performance etc.) context of the whole server-side JVM maybe, so you could do your own expiring of selected session data according to your own criteria.
Also I am thinking that recent computer science trends seem to be towards allowing flexible and more precise policy and hinting, on the API level, coupled with more intricate adaptive implementation internally.
That is how the overall Java Garbage Collection works, and I could imagine that a session object management system (or even a more general "scope object management system" for whatever scope, including application, session, request, tele-, peri-, or mouthwash) could work in a similar fashion (as another layer on top of the Garbage Collector).