diff --git a/spring-webflow-reference/src/flow-managed-persistence.xml b/spring-webflow-reference/src/flow-managed-persistence.xml index 82b09eb6..7ba9942b 100644 --- a/spring-webflow-reference/src/flow-managed-persistence.xml +++ b/spring-webflow-reference/src/flow-managed-persistence.xml @@ -4,7 +4,104 @@ Introduction - This chapter shows you how to use flows to manage web application persistence. + Most applications access data in some way. + Many modify data shared by multiple users and therefore require transactional data access properties. + This chapter shows you how to use flows to manage data access in a web application. + + + + Data access patterns + + There are essentially three flow-managed data access patterns: + + + The FlowScoped PersistenceContext + The ConversationScoped PersistenceContext + The ViewState PersistenceContext + + + Apart from these three patterns, there is the pattern of fully encapsulating PersistenceContext management within the service layer of your application. + In that case, the web layer does not get involved with persistence, instead it works entirely with detached objects that are passed to and returned by your service layer. + This chapter will focus on the flow-managed persistence patterns, exploring how and when to use them. + + + + FlowScoped PersistenceContext + + This pattern creates a PersistenceContext in flowScope on flow startup, + uses that context for data access during the course of flow execution, and commits changes made to persistent entities at the end. + This pattern provides isolation of intermediate edits by only committing changes to the database at the end of flow execution. + This pattern is often used in conjunction with an optimistic locking strategy to protect the integrity of data modified in parallel by multiple users. + To support saving and restarting the progress of a flow over an extended period of time, a durable store for conversational state must be used. + If a save and restart capability is not required, standard HTTP session-based storage of conversational state is sufficient. + In that case, session expiration or termination before commit could potentially result in changes being lost. + + + To use the FlowScoped PersistenceContext pattern, first mark your flow as a persistence-context: + + + + + + + +]]> + + Then configure the correct FlowExecutionListener to apply this pattern to your flow. + If using Hibernate, register the HibernateFlowExecutionListener. If using JPA, register the JpaFlowExecutionListener. + + + + + + + + + + + +]]> + + To trigger a commit at the end, annotate your end-state with the commit attribute: + + + +]]> + + + That is it. When your flow starts, the listener will handle allocating a new EntityManager in flowScope. + Reference this EntityManager at anytime from within your flow by using the special entityManager variable. + In addition, any data access that occurs using a Spring managed data access object will use this EntityManager automatically. + Such data access operations should always execute non transactionally or in read-only transactions to maintain isolation of intermediate edits. + + + + ConversationScoped PersistenceContext + + This pattern creates a PersistenceContext in conversationScope on flow startup, + and uses that context for data access until the conversation ends. + This pattern generally employs a manual flush mode; that is, the application decides when to flush changes to the database. + A convention for flow-managed flushing may be employed, such as always flushing after a transition one from one view-state to another. + This pattern provides no flow-level isolation of intermediate edits since flushing synchronizes persistent object state with the database. + With this pattern, all data access generally occurs non-transactionally. + + + + ViewState PersistenceContext + + This pattern creates a PersistenceContext with a read-only transaction before view rendering. + The context is used to load the model for the view. It stays open through view rendering and commits after rendering completes. + Then on the occurrence of an event, this pattern creates a fresh PersistenceContext with a read-write transaction. + The model is merged with the new context and any changes are committed after event handling completes. + Therefore, this pattern results in edits being saved to the DB after each event. Any rollback of intermediate flow steps requires compensating transactions. + This pattern is often used in conjunction with an optimistic locking strategy to protect the integrity of data modified in parallel by multiple users. + This pattern stores much less flow state, but generally increases the amount of data access since persistent entities are fetched and flushed more often. \ No newline at end of file diff --git a/spring-webflow-reference/src/views.xml b/spring-webflow-reference/src/views.xml index 333ec421..7b6849f4 100644 --- a/spring-webflow-reference/src/views.xml +++ b/spring-webflow-reference/src/views.xml @@ -272,6 +272,19 @@ public class BookingValidator { Such partial rendering is often used with events signaled by Ajax to update a specific zone of the view. + + Handling global events + + Use the flow's global-transitions element to create event handlers that apply across all views. + Global-transitions are often used to handle global menu links that are part of the layout. + + +<global-transitions> + <transition on="login"> to="login">> + <transition on="logout"> to="logout">> +</global-transitions> + + Working with messages