transactions and continuation support

[jocsch]

In the FlowExecutionStorage class I read that transactions and continuations does not work together. I disagree with the author of the javadoc commentar that these both things usually don't come together.
Think about a typical "buy" process off an online shop. The user will go through 5 pages to enter all details (and here continuations are really helpful to handle the back button) before he clicks on send. This is only allowed one time in the flow. So a typical candidate for a transaction.

Until now I haven't looked into the given workaround but I would say this is a typical scenario and should be supported "out-of-the box". Am I missing something. Maybe this can be achieved by using subflows?

[Keith Donald]

the issue is the default transaction syncronizer implementation relies on a token-based mechaism, where the token is managed in flow scope. this works fine for default sessino storage, but does not work when using continuations.

if you use continuations, you'll have 1 copy of the flow execution per request -- so there is no concept of a token here stored in a single, centrally managed flow execution. So for example, if I end the transaction in the last step of the flow, that clears the token for 1 copy only... if you refer to history, it'll be back and now you've got a duplicate submit.

In this case you need a custom TransactionSynchronizer impl that plays well with continuations and does not rely on flow scope (perhaps it uses the DB or a file). We'll want to consider providing out of the box implementatios and make it more easily pluggable in the future.

[klr8]

Continuations and application transactions don't really fit since continuations enable free browsing while application transactions are a textbook example of a controlled navigation.

Anyway, you can't really solve it with a subflow, since that will use the same storage strategy as the parent flow since both parent flow and sub flow are in the same flow execution and the storage strategy is on the flow execution level.

However, you could do it by launching the "transactional" flow from the end state of the "free browsing" flow. This will start a new flow execution and so you can change storage strategy to HttpSessionFlowExecutionStorage so that you can make use of application transactions safely.

Take a look at the new "FlowLauncher" sample application in CVS for an example of how to launch a flow from and end state of a previous flow.

Erwin

[jocsch]

OK. I currently try to figure out to use two flows to achieve the described behaviour.
But one thing I stumble across now is, that I can't start a transaction in my action (even without continuations). I try this

public Event prepareTx(RequestContext context) throws Exception {
  context.getTransactionSynchronizer().beginTransaction();
  System.out.println("init tX: "+context.getTransactionSynchronizer().inTransaction(false));
  return success();
 }

and the output it's always false. As the itemlist example is broken (at least in my build) I can't check if it behaves equally there. Anyway, I notice a difference between my flow and the itemlist flow. There the org.springframework.web.flow.mvc.FlowController has a property named synchronizeOnSession=true.
Is this important in this context as this is something that is not easily reproducable with the struts adapter (at least it seems so)?
Thanks,
Markus

[Keith Donald]

Ok, itemlist is back working. We introduced a side effect in the ExpiredFlowCleanupFilter--I've fixed it.

Study how itemlist works re: transacion synchronization. In short, you need to save the transaction token client side and submit it with the event--it must be present in the last event AND match the token in flowScope for the transaction assertions to hold true.