Support for maxConversations / maxContinuations on a flow-by-flow basis [SWF-359]

[spring-operator]

Denis Pasek opened SWF-359 and commented

Currently SWF does not provide good support for preventing double form submits.

As an example I will use the use case of banking transaction: the money transfer. The flow consists of 3 pages:

• input of transfer data
• authorization of money transfer
• confirmation page of successful transfer

The requirements are:

• no way to perform a double submit on the input data and the authorization page.
• It should be possible to use the back button for going back to the input data page from the authorization page.
• Going back from confirmation to authorization is not permitted.
• The confirmation page shows the transfer data and must be reloadable (hitting refresh button in browser).

Currently it's not possible to implement this kind of flow:

• if continuations are disabled, back button support is gone, but I cannot disable continuations because I have flows that are freely navigable in the same application.
• with continuations activated I have to reach an end state for avoiding double submits, but the confirmation page cannot be the end state because it wouldn't be reloadable.

I think Spring Webflow should implement the following enhancements better support of mixed flows:

• double click support for normal transition based on the conversation lock: The second request on the lock should result in exactly new state generated by the first request (continuations do not split the conversation into two paths).

• flag in flow definition for invalidating previous continuations during a transition, so you cannot go back to a page after this "point of no return".

• configuration of max. number of conversations and max. number of continuations should be per flow basis and not globally for the whole application.

---

Affects: 2.0 M1

Attachments:

• spring-webflow.tar.gz (10.05 kB)

Issue Links:

• #1017 Prevent back tracking once a certain step of a flow is completed.

• #147 Want to set expiration exclude conversation flow to ConversationContainer.

• #186 Prevent successive browser click events from resulting in duplicate transactions, while still displaying the transaction confirmation view.

• #186 Prevent successive browser click events from resulting in duplicate transactions, while still displaying the transaction confirmation view.

2 votes, 4 watchers

[spring-operator]

Erwin Vervaet commented

This is a duplicate of #1017 it seems, or certainly addresses a similar topic.

[spring-operator]

Denis Pasek commented

Yes #1017 addresses the same problem.

When addressing this problem please add my feature for defining the number of conversations and continuations in the flow definitiion and not globally.

[spring-operator]

Denis Pasek commented

Patch based on the current 1.0 maintenance branch for adding flwo attribute based control of number of conversations for a specific flow. As I mentioned before it would be a nice feature to control the number of possible conversations and the number of continuations for a specific flow based on flow definition attributes. The patched files include exactly this feature. The flow attributes "maxConversations" and "maxContinuations" are used for this purpose. If not specified the global value defined for the conversation manager / continuation repository will be used.

For controlling the conversation manager the attributes of the flow definition are added to the conversation parameters passed to the beginConversation() method.

For controlling the number of continuations the attribute will be retrieved from the flow execution instance to be stored.

To determine the id of the flow definition on a running conversation a CompositeConversatioId is used where the first part is the id of the flow definition.

The implementation has still one open issue. Since the conversations inside the ConversationContainer are stored in a map of lists (each flow definition will generate a map entry with the lists of conversation for this definition) the memory usage is increased since the removal of old flows will currently only work for each flow definition. If you use 5 conversations and you have 10 different flow this can currently result in 50 conversations in a worst case scenario. So the ConversationContainer needs some more polishing for being backward compatible to the old semantics of maximum number of conversations.

I think this patch maybe a good strating point for you to extend SWF with this kind of fine grained control.

[spring-operator]

Keith Donald commented

Hi Denis,

Can you expand on this point?

• double click support for normal transition based on the conversation lock: The second request on the lock should result in exactly new state generated by the first request (continuations do not split the conversation into two paths)

I want to consider each enhancement then have a JIRA issue to track each. More info on this one will help...

[spring-operator]

Keith Donald commented

Updating this issue to be more fine grained.

[spring-operator]

Denis Pasek commented

Hi Keith,

I've added my comments on the double click issue to issue #186.