About the Memory Scopes of the ADF 11g

By W.ZH abstracted from Fusion ADF 11g dev guide, Feb 2009At runtime, ADF objects such as the binding container and managed beans

are instantiated. Each of these objects has a defined lifespan set by its scope

attribute. You can access a scope as a java.util.Map from the RequestContext API.

For example, to access an object named foo in the request scope, you would

use the expression #{requestScope.foo}.

There are six types of scopes in a Fusion web application:

■ Application scope: The object is available for the duration of the application.

■ Session scope: The object is available for the duration of the session.

Note: There’s no window uniqueness for session scope, all windows

in the session share the same session scope instance. If you are

concerned about multiple windows being able to access the same

object (for example to ensure that managed beans do not conflict

across windows), you should use a scope that is window-specific,

such as page flow or view scope.

■ Page flow scope: The object is available for the duration of a bounded task flow.

Note: Because these are not standard JSF scopes, you cannot registera managed bean to these scopes. However, the value of a managed

bean property can refer to values in these scopes.

Also, EL expressions must explicitly include the scope to retrieve

values. For example, to retrieve foo from the pageFlowScope scope,

your expression would be #{pageFlowScope.foo}.


■ Request scope:
The object is available from the time an HTTP request is made until

a response is sent back to the client.

■ Backing bean scope: Used for managed beans for page fragments and declarative

components only, the object is available from the time an HTTP request is made

until a response is sent back to the client. This scope is needed for fragments and

declarative components because there may be more than one page fragment or

declarative component on a page, and to prevent collisions, any values must be

kept in separate scope instances. Therefore, any managed bean for a page

fragment or declarative component must use backing bean scope.

A backing bean is a managed bean that contains accessors for a UI component.

Backing bean scope has a lifespan of a single request and provides an isolated instance

of memory for backing beans. Other than having a different scope, management of

backing beans in this scope is no different from other application beans already

managed by ADF, such as page flow scope and view scope beans.

Note: Because these are not standard JSF scopes, you cannot register

a managed bean to these scopes. However, the value of a managed

bean property can refer to values in these scopes.

Also, EL expressions must explicitly include the scope to retrieve

values. For example, to retrieve foo from the backing bean scope,

your expression would be #{backingBeanScope.foo}.

■ View scope: The object is available until the view ID for the current view activity

changes. You can use view scope to hold values for a given page. While request

scope can be used to store a value needed from one page to the next, anything

stored in view scope will be lost once the view ID changes.

A view scope instance exists for each view port that the ADF Controller manages, for

example, a root browser window or a region. The lifespan of a view scope instance

begins and end when the current viewId of a view port is changed. If you specify

view scope, JDeveloper retains objects used on a page as long as the user continues to

interact with the page. These objects are automatically released when the user leaves

the page.

Note: Because these are not standard JSF scopes, you cannot register

a managed bean to these scopes. However, the value of a managed

bean property can refer to values in these scopes.

Also, EL expressions must explicitly include the scope to retrieve

values. For example, to retrieve foo from the view scope, your

expression would be #{viewScope.foo}.

Object scopes are analogous to global and local variable scopes in programming

languages. The wider the scope, the higher availability of an object. During their life,

these objects may expose certain interfaces, hold information, or pass variables and

parameters to other objects. For example, a managed bean defined in session scope

will be available for use during multiple page requests. However, a managed bean

defined in request scope will only be available for the duration of one page request.

By default, the binding container and the binding objects it contains are defined in

session scope. However, the values referenced by value bindings and iterator bindings

are undefined between requests and for scalability reasons do not remain in session

scope. Therefore, the values that binding objects refer to are valid only during a

request in which that binding container has been prepared by the ADF lifecycle. What

stays in session scope are only the binding container and binding objects themselves.

Figure 19–3 shows the time period during which each type of scope is valid.

 

Advertisements