Seam Learning (IV)-context variables and search priorities

Context variables)

The context defines the namespace, a groupContext variables). These work is similar to the definition of session or request attributes in servlet specifications. You can bind any value you like to context variable, but we usually bind the seam component instance to context variables.

Therefore, in the context, the component instance is identified by the context variable name (normally, but not absolute, just like the component name ). You can useProgramAccess the named component instance within a specific range.ContextsClass, which providesContextAccess to instances bound to several threads of the interface:

 
User user = (User) contexts. getsessioncontext (). Get ("user ");
 

You can also set or modify the variable value by name:

 
Contexts. getsessioncontext (). Set ("user", user );
 

However, we usually obtain the component from the context through injection, and return the component instance to the context through outjection.

Context Search priority

Sometimes, as shown in the preceding example, a component instance is obtained from a specific known range. In other casesPriority Order (Priority Order)Search within all stateful ranges. The order is as follows:

• Event Context

• Page Context

• Conversation Context

• Session Context

• Business process context

• Application Context

You can callContexts. lookupinstatefulcontexts ()To perform a search with priority. When you access a component by name on the JSF page, the search with priority is executed.

Concurrency Model

The Servlet and EJB specifications do not define any terms on how to manage concurrent requests from the same client. Servlet containers simply allow all threads to run concurrently and hand over tasks of thread Resource Security sharing to applicationsCode. The EJB container allows concurrent accesses to stateless components, but if you access a stateful Session Bean concurrently, an exception is thrown.

Old web applications are written around fine-grained synchronous requests, so this behavior may be OK. But for modern programs, because a large number of fine-grained asynchronous (Ajax) requests are used, concurrency actually exists and must be supported by the program model. Seam adds the concurrency management layer to its context model.

The seam session and application context are multithreading. Seam allows concurrent requests in an context for concurrent processing. The event and page context are naturally single-threaded. The business process context is strictly multi-threaded, but concurrency is rare in actual situations. Therefore, concurrency is not used in most cases. Finally, seam providesSingle thread per process for each conversationModel, which is achieved by serializing concurrent requests in the same long-running dialog context.

Because the session context is multi-threaded and often contains unstable states, components within the session range are always protected by seam to prevent concurrent operations. By default, seam serializes Session Bean and JavaBean requests within the session range (and detects and solves any deadlocks ). For application scoped components, this is not the default behavior, because application scoped components generally do not contain unstable states, and the global synchronization costExtremelyHigh. However, you can force a serialized thread model for any session bean or JavaBean Component to add@ SynchronizedAnnotation.

The concurrency model means that the Ajax client can safely use unstable sessions and session States without the need for developers to do any special work.