session vs request

There is good explanation from BluePrint:

[ From Some other Post on Sun forum ]

Request scope

Information in this scope is created some time after the request is received and is disposed of some time after the response is complete. It is a good practice to have the backing beans for pages be in the request scope where possible, and maintain separate beans that store only the information that will not need to be continually passed between the client and server.

The following types of information are good candidates for storing in the request scope:

* Value bindings (e.g. <h:inputText value="#{MyBean.lastName}" /> should always be stored in request scope since they are automatically restored on every request.

* Component bindings (e.g. <h:inputText binding="#{MyBean.lastNameComponent}" />) should always be stored in request scope since their value is no longer valid after a request has been processed anyway. The component tree is reconstituted during each incoming request, changing the physical instances these component bindings will point to.

* References to database resources such as connections, statements, and result sets should be properly closed and discarded before a request is complete (see the section on resource management below for details).

* Caches of database query results - see section on caching database query results for details.

* Temporary results of calculations used for rendering the current view.

Session scope

Information in this scope is created some time after the current user's first request is received and is disposed of after a configurable period of inactivity (i.e. when a request has not been received in a certain period of time), or when a session is explicitly invalidated by the application. It is also disposed of when the application is undeployed. Depending on the robustness of the application server, it may also be disposed of when the application server is shut down or crashes.

The following types of information are good candidates for storing in the session scope:

* Navigational context, for example the album the user is currently editing in a music catalog application. This type of information could potentially be carefully passed back and forth via hidden input fields, but this is error prone and can be difficult to manage together with form validation and when forms are shared between different parts of an application.

* Information that is specific to this session, but temporary, such as short-lived shopping carts. The information can be made persistent by also updating a database table. The recommended way to do this is via entity EJBs, but this can be done by manually coding database-aware JavaBeans as well.

* Security sensitive information that should not be continuously sent back and forth between the client and server.

* Caches of database query results - see section on caching database query results for details.

Application scope

Information in this scope is created some time after the application is deployed and is discarded some time before the application is undeployed. Depending on the robustness of the application server, it may also be disposed of when the application server is shut down or crashes.

The following types of information are good candidates for storing in the application scope:

* Information that transcends particular users or sessions, such as application settings.

* Caches of database query results - see section on caching database query results for detail

//PremInd

http://anupampawar.googlepages.com

PremInda at 2007-7-12 19:38:02 >