Transaction rollback in action pipeline

[beve]

When using a global transaction with an action pipeline it is possible for a participant in the transaction to rollback the transaction. For example, an action invoking a database, could call rollback on the connection and have the global transaction rolled back.

But we are also seeing the need to be able to trigger a rollback from other actions in the pipeline.

One use case we have is where we are calling external webservices.
These webservices sometimes respond with faults, like the service is temporarliy unvailable or something like that.
We need to be able to resend these request to the webservices and thought we would use transactions for this.
When we receive a fault we would like to rollback the transaction, which will put the JMS message back on the queue for pickup. (assuming JMS transport here)

This in combination with specifying JCA/JMS redelivery properties like MaxDeliveryAttempts and RedeliveryDelay we can achive what we want.
For more information about how this redelivery could work see this jira : http://jira.jboss.com/jira/browse/JBESB-1563.

The problem is that to rollback the transaction we must throw a RuntimeException.

Is there a way to rollback the transaction in an action pipeline without throwing a RuntimeException?

Should we create an execption specifically for this need that can be used by actions, like a RollbackException?

Any thoughs on this?

Thanks,

Daniel

[marklittle]

Have you looked at the TransactionStrategy class(es)?

[beve]

Ah, thanks for the hint!

So something like this in a customer action:

TransactionStrategy strategy = TransactionStrategy.getTransactionStrategy(true);
strategy.rollbackOnly();

/Daniel

[beve]

That worked like a charm! Thanks

So the only thing I need now is a green light to commit work for http://jira.jboss.com/jira/browse/JBESB-1563 ;)

Would that be ok?

Thanks,

Daniel

[kconner]

Hiya Daniel.

You can certainly go ahead and commit on JBESB-1563. Please make sure that these activation properties cannot overwrite the ones created in the configuration mapper though, our attributes need to take precedence.

Kev

[beve]

Is this what you mean:

/*
 * Add user specified activation-config. These may be overridden if one of:
 * - destination
 * - providerAdapterJNDI
 * - destinationType
 * - messageSelector
 * - maxMessages
 */
ActivationConfig activationConfig = jmsJcaProvider.getActivationConfig();
if ( activationConfig != null )
{
 List<Property> propertyList = activationConfig.getPropertyList();
 for (Iterator<Property> iterator = propertyList.iterator(); iterator.hasNext();)
 {
 Property prop = iterator.next();
 addPropertyElement(activationConfigElement, prop.getName(), prop.getValue()) ;
 }
}
...
set the other config properties
...

I'll update the jms_transacted quickstart after it is merged back into the main trunk.

/Daniel

[kconner]

Hiya Daniel.

That would certainly work as a minimum but it would be better if it detected the use of any of our explicit activation properties and threw a ConfigurationException.

Kev

[beve]

Hey Kevin,

yeah, that would be much better. I'll reopen and add that.

Thanks,

/Daniel