Transactions

[danielm]

I have followed the item list example for setting up and checking for a valid transaction, but have noticed some strange behaviour. When I check for a valid transaction in the action state that a form submits to, result is true. If I make the check in a subsequent action state which is reached through the success transition of said action, it is false.

Any ideas on how to solve this?

Thanks
Daniel

[klr8]

How are you doing the "check"? Make sure you are passing "false" to the end parameter of the assertInTransaction or isInTransaction methods.

Erwin

[danielm]

I am passing in false to the isInTransaction method

[danielm]

I begin the transaction with

context.getTransactionSynchronizer().beginTransaction();

And check in a subsequent action state using

if(!context.getTransactionSynchronizer().inTransaction(false)){
  //do error stuff
}

If this action state is after a form submission, which submits the token, its all good. If the action state follows on from another action state ie

<action-state id="validateApplication">
		<action bean="applicationWorkflowAction" method="validateApplication"/>
		<transition on="success" to="submitApplication"/>
                <transition on="error" to="applicationForm"/>
	</action-state>

Where validateApplication is reached from a form submission and the transaction check returns true, in submitApplication however the transaction check returns false.

[danielm]

Following this through the debugger it looks as though in the second state, the Event returned by context.getLastEvent() has no parameters, which obviously means no transaction token. The same is true when getLastEvent() is called in the inTransaction() method of InternalRequestContext.

Is this the expected behaviour?

[klr8]

No it is not. This is a bug. The system should always try to find the transaction token in the originating event of the request context to verify that the client is "in" the transaction.

I've fixed the bug and the new code is in CVS. This will ofcourse also be included in the Preview 3 release.

Erwin

[danielm]

Excellent, thanks for the response and the fix

[danielm]

Prior to this fix, I was able to press the back button and submit a form again to test that the transaction code was working, but now when doing this a NoSuchFlowExecutionException is thrown. Is this correct? Also what is the recommended way of dealing with such exceptions?

[Keith Donald]

Daniel,

Has your flow ended (reached an end state) when you attempt to do this? If so, that explains the NoSuchFlowExecutionException. You could always catch that and reroute the user to a error page that allows them to restart a new flow if they'd like to.

Keith

[danielm]

The flow has ended at this point.

Does webflow provide any mechanism to catch exceptions such as this? My solution at the moment is to declare it as a global exception in my struts config which obviously isn't ideal as there can only be one place it can go to, rather than a 'handler' per flow.