>From: Simon Laws [mailto:[email protected]] >Sent: Wednesday, August 18, 2010 4:58 PM >To: [email protected] >Subject: Re: Question: Injected callback proxies vs. requestContext [...]
>What actually happens is that the instance of the request context >object itself is not important but when you call its methods it >rummages around and pulls the correct information out of the thread so >that the correct callback proxy is made available. I'll see if I can >make the text explain that better. thanks. I'll have a look at the source code to understand how the rummaging around is done. >Re. single threaded execution. The place that you are ensured that >only a single thread is executing in a component instance at any one >time is when a component has STATELESS scope. The default. In this >case a new component instance is created for each request. I'm not >sure if that's answering your question though as you talk about >"access to a service" so let me know if there is more to your >question. Yes, I was thinking along the following lines: Suppose you have a component which must be COMPOSITE scope for reasons of its own. As it happens, when you developed it this component would be accessed only by one client at a time, so you never bothered to make it threadsafe. Now the deployment context changes and suddenly the component gets hit with concurrent requests. Wouldn't it be nice if there were a way to declare this component as "non-concurrent" (or whatever) in its configuration file (the composite.xml) instead of having to change the code to make it threadsafe? The Tuscany runtime would so be made responsible for blocking concurrent access. -- Sebastian
