Millies, Sebastian wrote:
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
>
You should be able to achieve the same effect by declaring all the
methods of the implementation class as synchronized. I think it's
the responsibility of the implementation to protect itself in this
case, either by thread-safe code or by using synchronized methods.
Simon
