HttpSession handling

[jocsch]

The HTTPsession handling of SWF is not very clear to me. May be you can comment on the following statements:

• - a httpsession is created latest when a flow is started
  - if a flow reaches the end status is the httpSession invalidated or is the flow stuff simply removed from the httpSession (depending on who created the httpsession?)?
  - if I use httpSessionContinuationStorage the flow stuff is not removed from httpSession in the end status, or? Instead the ExpiredFLowCleanupFilter is used to determine unused flows and remove them.
  - how can I influence the HttpSession after a flow has ended? E.g. think of a Registration wizard which auto login a user at the end (which requires the authentication information in the session), or a immediate invalidate of the session. I would expect to use a FLowExecutionListener but it is very clear stated in the docs that the parameters are not linked against the httpRequest or the httpSession.

Would be great to get clarifications on these ones.
Thanks,
Markus

[Keith Donald]

This is a repost from another topic, but it should answer most of your questions:

If an exception is thrown up the stack and caught by the dispatcher servlet and routed to a error page, the flow execution by default will continue to sit around in the session until the session expires; that is, if you are choosing to persist your flows in the session. The same applies if I start a flow and then go to the bathroom and don't come back for awhile.

With that said, there is a ExpiredFlowCleanupFilter you can install that will automatically detect and cleanup expired/abandoned flows. See the web.xml file of the ItemList sample, which illustrates this.

Also, if you're using a client-continuation based flow execution storage strategy, no cleanup is neccessary as there is no session state.

On the other hand, If you're using a http session continuation based flow execution storage strategy (sellitem does this by default), a new copy of the flow execution is created and stored in the session on each flow request. This is the most expensive strategy in terms of storage, but the most flexible with regards to state restoration (e.g allowing proper back button use--as you can restore the flow at any point from a unique, cached flowExecutionId in local history.)

So of the three flow execution storage strategies, the default "session" requires some storage, but not as much as the "continuations-based session" strategy. In those cases, the ExpiredFlowCleanupFilter can help for abandonded/errored out flows, as normal flows that reach a end state will always be cleaned up automatically. The client strategy requires no session state at all, but has some other tradeoffs (e.g security issues, limitations with GET

[jocsch]

hi keith,
thanks so far but the most important point for me is still open: How to communicate from the flow to the rest of the application. See the register wizard example. Is this possible. I think this functionality would be quite equal to the ParameterizableFlowAttributeMapper but it maps back to HTTPSession instead of a FlowSession.

[Keith Donald]

Markus,

I'd use the FlowExecutionListener -- just grab the HttpSession there in your flowEnded callback. You can do it like this:

((HttpServletRequestEvent)context.getOriginatingEv ent()).getRequest.getSession()

[jocsch]

That forced me to add listener support to the struts adapter. It's a simple one (questionable if the effort adding this to jiira is worth the work ;-)):

See SPR-902 in jiira.

[mirceade]

With that said, there is a ExpiredFlowCleanupFilter you can install that will automatically detect and cleanup expired/abandoned flows.
Ho do you do that in Webflow 2?

[Rossen Stoyanchev]

I'm not aware of anything to that extent but you can control the number of concurrent flow executions through attributes on the flow-execution-repository element in the Web Flow 2 configuration namespace.

[mirceade]

I'm aware of that ( <webflow:flow-execution-repository max-executions="1" max-execution-snapshots="0"/>, for example ) but I needed some processing to be done on conversation expiry.