The previous sections explained the differences between global and session scope. Nucleus also includes a third scope, called request scope. If a component is marked with request scope, then simultaneous requests will all see a different copy of the component. This is true even if two requests from the same session come in at the same time (as might happen when frames are involved).
If a component is marked with request scope, then you are guaranteed that no other request will be able to affect that component while your request is being handled. If another request comes in at the same time and names the same component, both requests will get pointers to different objects.
Request scope components are most useful when processing the results of a submitted form. When a form is submitted, the submitted values are set into the component by calling the appropriate setX methods, and actions are performed by calling the appropriate handleX methods. In this model, these operations are not necessarily atomic. If two forms are submitted at the same time to the same component, it is possible that the two submissions will overwrite each other’s setX methods. This is likely to be the case for global scope components, and is unlikely but still possible for session scope components. With request scope components, each request is guaranteed to get its own copy of the component, so the possibility of overwriting is eliminated.
Note that another way to handle this problem in some cases is to use a global or session scoped component in a form, but use the synchronized attribute to ensure that the form is handled appropriately. See the Creating Forms chapter in the ATG Page Developer's Guide for more information.
A request-scoped component may have properties that point to objects of any scope. Dynamo correctly connects the request-scoped component to the appropriate component for that request.
On the other hand, global and session-scoped components should not have pointers to request-scoped components. This is because request-scoped components are constantly being created, destroyed, and shuffled around between requests. It is a very bad idea for anything other than another request-scoped object to hold onto a pointer for a request-scoped object.
The Request Scope Manager component (Nucleus address /atg/dynamo/servlet/pipeline/RequestScopeManager) allows you to view the request-scoped Nucleus hierarchy for the last few requests made to the Dynamo server. Every time a request comes into the browser, it creates a request scope and a tree of components. Request scopes are recycled as requests come in to the server.
Preserving Request Scope on Redirects
If a request results in a redirect to a local page (when you use the HttpServletResponse.sendLocalRedirect() method), the ATG platform treats the redirect request as part of the original request for the purposes of request-scoped components. This allows you to preserve any request-scoped objects associated with the original request, rather than losing them when the request results in a redirect. To implement this, the ATG platform adds an additional query parameter named _requestid to the redirected URL. You can change this behavior by setting the following property of the /atg/dynamo/servlet/pipeline/RequestScopeManager component:
saveRequestScopeOnRedirect=false
