Oops, I see that ReferenceBindingProvider2.supportsAsyncOneWayInvocationaccomplishes what I want to do. Thanks.
On 8/3/07, Greg Dritschler <[EMAIL PROTECTED]> wrote: > > 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 >
