Like anything, however, there are trade-offs. And continuations are no exception.
Specifically:•Creating copies of a FlowExecutionto support restoration increases memory require-
ments. There is also some CPU overhead, as copies are created (based on serialization
by default, which also requires objects in flow scope to be serializable).•A copy is a snapshot of the FlowExecutionat a point in time. If you go back to a previous
snapshot, you lose data collected by later snapshots. This “undo” behavior may not be
what users expect.•Sometimes you don’t want to allow back under any circumstances. For example, con-
sider a step in a flow that inserts a token in a database table. You want to make sure that
step executes once, and only once in the logical conversation. If a continuation is cre-
ated for every view state, nothing is stopping the user from going back in history and
reexecuting that step.These trade-offs are manageable, but it is important to note that implementing a robust
continuation server is not a trivial undertaking.
To address memory concerns, continuations can be expired after a configurable idle
period, and the maximum number of continuations allowed per conversation can be capped.
As for the second “undo” issue, this in large part requires exercising caution on the part of
the web developer. Data placed in flow scope is really associated with a continuation. So if you
go back and reference a continuation created at a previous point in time before the data was
created, the data will no longer be there when you continue from that point. Likewise, if the
data was created during the execution of a subflow, going back to a previous continuation
may restore to a point before the subflow was even launched!
To deal with this, Spring Web Flow provides access to more globally scoped data struc-
tures like conversational and session scope, which are shared by all continuations associated
with a logical conversation. Data placed in these scopes remains there even if you go back and
restore a previous continuation. It is very important to understand the semantic differences
here.
To the third point, continuations can be explicitly invalidated. For example, assume after
view state number three of a ten-view-state flow, all previous FlowExecutionContinuations
should be invalidated, preventing use of the Back button for those steps from that point on.
This can be metadata driven, for example by marking a view state as “nonrepeatable.” In addi-
tion, all continuations associated with a logical conversation can be automatically invalidated
after it is determined the conversation “ends” (by one of the continuations reaching an end
state).
■NoteThe memory expense of using a continuations-based implementation depends somewhat upon
where the continuations are stored. If they are stored on the client (as you will see), there is actually no
server-side state at all.
CHAPTER 12 ■ADVANCED SPRING WEB FLOW 355