Re: [mule-scm] [mule] [11755] branches/mule-2.0.x/transports/vm/src/test/resources: MULE-3318 - Add missing transaction pieces for vm transport in dispatcher and turn on vm transaction tests again.

View: New views
2 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: [mule-scm] [mule] [11755] branches/mule-2.0.x/transports/vm/src/test/resources: MULE-3318 - Add missing transaction pieces for vm transport in dispatcher and turn on vm transaction tests again.

by Andrew Perepelytsya :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Andreas, shouldn't a transaction enforce sync execution? This line might need to be changed then:

return receiver.onCall(event.getMessage(), event.isSynchronous());

Andrew

Re: Re: [mule-scm] [mule] [11755] branches/mule-2.0.x/transports/vm/src/test/resources: MULE-3318 - Add missing transaction pieces for vm transport in dispatcher and turn on vm transaction tests again.

by Andreas Guenther-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Good point. Looking at the actual call resolution of onCall() we'll end
up here:

    public final MuleMessage routeMessage(MuleMessage message, boolean
synchronous) throws MuleException
    {
        Transaction tx =
TransactionCoordination.getInstance().getTransaction();
        return routeMessage(message, tx, tx != null || synchronous, null);
    }

Still, I agree that we could make it more clear by setting sync to true.
Looking deeper into AbstractMesageReceiver some clean-up could be done
in the same direction, too. I'll commit the suggested change as a follow-up.

Thanks,
-Andreas

Andrew Perepelytsya wrote:
> Andreas, shouldn't a transaction enforce sync execution? This line
> might need to be changed then:
>
>     return receiver.onCall(event.getMessage(), event.isSynchronous());
>
>
> Andrew


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email