If a component has request scope then the behaviour of the component, w.r.tconversations, currently differs depending on whether it is accessed via a local or a remote binding. Consider components A and B where B has request scope and A sends messages to B over local and remote bindings in the content of two conversations. The sequece of messages will be.
conversation1.initCount(1) conversation1.incrementCount() result = conversation1.getCount() In the local case component B is always on the same thread as component A and, regardless of which conversation is actually calling B the same component instance is used. This component instance adopts the conversation ID (through @ConversationID) it was created with regardless of which conversation is actualy calling B. The result is the following sequence of calls init,initializeCount,incrementCount,retrieveCount,endConversation In the remote case a new component B instance is created for each call and hence B adopts the conversation ID from the incoming message. The resulting the sequence of messages is. init,initializeCount,init,incrementCount,init,retrieveCount,init,endConversation Note. A new instance is created and init() is called for each message. The assemble spec describes request scoped components in the following way. 285 1.2.4.2. Request scope 286 The lifecycle of request scope extends from the point a request on a remotable interface enters the SCA 287 runtime and a thread processes that request until the thread completes synchronously processing the 288 request. During that time, all service requests will be delegated to the same implementation instance of a 289 request-scoped component. 290 There are times when a local request scoped service is called without there being a remotable service 291 earlier in the call stack, such as when a local service is called from a non-SCA entity. In these cases, a 292 remote request is always considered to be present, but the lifetime of the request is implementation 293 dependent. For example, a timer event could be treated as a remote request. Is our interpretation of the behaviour of request scoped components within a conversation correct? Regards Simon