The seam context is created and destroyed by the framework. Application Program Context division cannot be controlled through explicit Java API calls. The context is usually implicit. However, in some cases, context can be divided by annotation (annotation.
The basic seam context is:
You may have seen some of the contexts in Servlet and related specifications, but two of them may have never seen:Conversation Context), AndBusiness process context). In Web applications, the reason why status management is so messy and error-prone is that the three built-in contexts (request, session, and application) are not meaningful from the perspective of business logic. For example, the construction of a user login session is quite random for the actual workflow of the application. Therefore, most seam components are limited to business sessions or business process contexts, because these contexts are most meaningful from the application perspective.
Let's examine each context in order ).
(1) stateless context (stateless context)
Those components that are indeed stateless (mainly stateless session beans) are always running in stateless context (actually context-independent ). Stateless components do not mean much, and they are also controversial because they are not very object-oriented. However, they are important and usually useful.
(2) event context)
The event context is the "shortest" stateful context, which is a generalization of the Web Request context to include other types of events. However, the event context associated with the life cycle of the JSF request is the most important instance of the event context, and is also the most common deal. Components associated with the event context are destroyed at the end of the request, but their statuses exist at least in the request lifecycle and are well defined.
When you call the seam component through RMI or seam remoting, an event context is created and destroyed for this call.
(3) Page Context)
Page Context allows you to associate the status with an instance of a rendered page. You can initialize the status in the event listener, or initialize the status when rendering the page. Any event originating from the page can access the status. This feature is particularly useful when supporting clickable lists. The list content is generated by data changes on the server. In fact, the status is serialized to the client, so this structure is very robust when performing multi-window operations or rollback buttons.
(4) conversation context (Business Session Context)
Business session context is the core concept in seam.Conversation)It is a unit of work Viewed from the user's perspective. It may span multiple Servlets, multiple requests, and multiple database transactions that interact with users. However, for users, a business session solves a single problem. For example, "booking a hotel", "approving a contract", and "Creating an order" are all business sessions. You can think of business sessions as an implementation of "Use Case" or "User Story". Of course, the specific business associations are not exactly the same as such examples.
The business session is saved in the "What are users doing in this window" status. At any time, a user may be in multiple business sessions at the same time, usually in several different windows. The business session context allows us to ensure that the statuses of different business sessions do not interfere with each other and do not cause bugs.
It may take you a little time to get used to thinking about your application from the perspective of this business session. But once you get used to it, you will like this term and will no longer think about it without business sessions!
Some business sessions exist only in one request. Business sessions of multiple cross-origin requests must be divided by the annotation provided by seam.
Some business sessions are alsoTasks). A task is a business session. It refers to a business process that runs for a long time. After a task is completed correctly, a state transition of the business process may be triggered. Seam provides special annotations for task division.
The business dialog can beNested)A business dialog is nested in a larger business dialog. This is an advanced feature.
Generally, the business conversation state is actually saved by seam in the servlet session, spanning requests. Seam implements configurableConversation timeoutAnd can automatically destroy non-active business sessions. This ensures that, if the user cancels the conversation, the State stored in the user's login session will not grow infinitely.
For concurrent requests generated in a long running business session, seam is executed in order.
In addition, seam can be configured to save the dialog state in the client browser.
(5) Session Context)
The Session Context stores the status associated with the user's logon session. Although this is useful when you need to switch the status in multiple business sessions, we generally do not recommend using the Session Context save component unless it stores global information about the logged-on users.
In the JSR-168 portal environment, Session Context represents the Portlet context.
(6) Business process context (Business Process context)
The business process context stores the status related to the business process that has been running for a long time. This state is managed and persisted by the BPM engine (jbpm. The Business Process spans the interaction of multiple users, so the state is shared among multiple users in a well-defined manner. The current task determines the current business process instance.Process Definition Language)Therefore, no special annotation is used to divide business processes.
(7) application context)
The application context is the servlet context in the servlet specification. The application context is useful for saving static information, such as configuration data, reference data, or metadata. For example, seam stores its configuration and metadata in the application context.