A NonBlockingInterceptor is inserted into invocation chains for all oneway methods. This causes a problem when a component invokes a oneway method over a binding that supports transactional messaging, such as JMS. The binding must run on the client's thread in order to enlist in the client's transaction. It can't do this because the NonBlockingInterceptor switches the invocation off the client's thread to a new thread that doesn't have the same transaction context. It isn't practical or efficient for the WorkManager to propagate transaction context to the new thread.
I think the binding needs to be consulted before the NonBlockingInterceptor is added to the chain. I propose adding a method to org.apache.tuscany.sca.assembly.Binding along the lines of boolean isOneWayCapable(); CompositeActivatorImpl would call this method before adding the NonBlockingInterceptor to the invocation chain. It would only add the interceptor if the method returned false. I think any binding that natively supports oneway messages could return true, regardless of whether the message delivery is transacted or not. Bindings that do support transacted sends could make a decision based on policy. For example if the default binding were to support transacted sends, it could return true if a transacted send is required and false if a transacted send is not required and a simple thread switch will do. I can submit a patch to support the interface. I wanted to get some feedback first since it does require a minor SPI change. Greg
