> From: Peter Donald [mailto:[EMAIL PROTECTED]]
>
> At 03:00 PM 6/12/2002 -0500, you wrote:
> >Hello, I have been silently following the recent discussion
> on the new
> >CM and have a question about what it means for a component
> to be thread
> >safe.
> >
> >In my mind I feel that thread safe is being mixed up with
> "stateless".
>
>
> Yep ;) We definetly need to be clearer on terminology usage.
Let's nail down the requirements for Threadsafe. As I see them:
1) The component either needs to be stateless, or it must associate
its state/session information with the client (calling entity).
2) The component must be fully reentrant (must be able to process
a request from one client while operating on another client)
* Simple but effective approach would be to make the calling
method synchronized--only one client at a time.
- Less performant due to thread contention for the prized
method
- Easier for developer to do
* More proper way would be to have any processing variables be
local to the method, and store any state/session info with
the client.
- More performant because there is no locking necessary, or
locking is restricted to a few small, quickly executing
critical blocks of code.
- More difficult for the developer, and _*a lot*_ of testing
is necessary.
3) Cannot impose a defined order of calling methods *unless* state
is maintained with the client.
I'm probably missing something, but those are the two biggies.
Any stateless component that defines only one method (or a choice
of methods that do essentially the same thing) can be ThreadSafe.
Not all components are as trivial as this, though.
A stateless component that defines several methods that are not
required to be called in a predefined order can be ThreadSafe.
Same thing as before--this doesn't satisfy all components.
Any time the Component's interface defines methods that must be
called in a predefined order does not necessarily preclude the
ability to write a ThreadSafe component--but it is much more
difficult. In order for such a component to become threadsafe,
the client either needs to hold a "Session" object (an object
shared between the Component and the client), or the framework
has to provide one. Since nobody wants to try and have a session
object work at the framework level, it does not preclude the
possibility of using one. Look at the example below:
interface MySessionEnabledComponent
{
Session start(...); // arguments necessary to start processing
bool isFinished(Session ses);
Object getResult(Session ses);
}
This places the session management directly with the client--while
not always optimal, it gets the job done.
However, another more subtle way of doing _essentially_ the same
thing is to return a processing artifact. That requires rewriting
the component interface, but the effects are better:
interface MyInvisibleSessionComponent
{
Query start(...); // arguments necessary to start processing
}
interface Query
{
bool isFinished();
Object getResult();
}
The component itself now becomes stateless, and merely kicks off
processing objects like the Query interface defined above. The
Query is unique to every caller, and in this case acts like a
"Future" (an object that continues to process a result asynchronously
and doesn't block until you need the answer).
The approach is more subtle, does not have any obvious state or
session management happening, and provides a *discardable* object.
The important thing about the discardable object is that it is low
cost to instantiate, and is easily garbage collected. Therefore
no pooling of resources is necessary.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
