avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Patch] New Avalon Docs
Date Tue, 17 Jul 2001 13:19:27 GMT
Leo Sutic wrote:
> 
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: den 17 juli 2001 14:26
> > To: Avalon Development
> > Subject: Re: [Patch] New Avalon Docs
> >
> >
> > Leo Sutic wrote:
> > >
> > > (framework.xml)
> > > (...)
> 
> > What was your issue/update here?  I did not see any comments
> > about this block.
> 
> None at all, I just included it as a contrast to the text in
> implementing.xml.
> 
> > > (implementing.xml)
> > >
> > > "org.apache.avalon.framework.thread.Threadsafe
> > >
> > > Component does not maintain state between method calls,"
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >
> > > I do not see this as being a necessary part of the contract.
> > This would mean
> > > that a component that maintains state can not implements its
> > own locking and
> > > mark itself ThreadSafe.
> >
> > When I wrote that, I was thinking of an interface like SAX.
> > There is a specific
> > sequence of method calls, and not context/session object to pass
> > to each method.
> > In instances like that the interface precludes ThreadSafe
> > operation.  Do you have
> > clearer text that makes that obvious.
> 
>  - Component is required to serialize access to shared resources.
>  - Component will not receive any context/session objects, as it is shared
> among different contexts/sessions.

Your first bullet applies.

Your second bullet is (I think) a little off.

If you have an interface like this:

interface OrderedMethods {
    void callMeFirst(String modifier);
    void callMeSecond(String modifier);
}

Cannot be ThreadSafe by definition.  There is a specific ordering of methods,
and the Component cannot be guaranteed that another thread won't call method 2
directly after your thread called method 1.  This is the issue I am trying to
address.  For the purposes of our discussion, the "modifier" parameter has meaning
to the component, but not as an identifier.

In order to make this ThreadSafe, and maintain separate methods, you must change
it to INCLUDE a session identifier:

interface OrderedMethods {
    int getSessionId();
    void callMeFirst(int sessionId, String modifier);
    void callMeSecond(int sessionId, String modifier);
}

As you can see, we now have a way of identifying the caller.  This is not required
if we only had one method:

interface OneMethod {
    void callMe(String firstModifier, String secondModifier);
}

Now, all state management for this "session" is handled in one method.  There is
no order we have to preserve or manage.

Encapsulating this, however, is not easy.

> Besides that, your point that:
> 
>  - One instance is created and shared with all Composables that request it.
> 
> is enough.

Ok.

> And one more thing:
> 
> org.apache.avalon.excalibur.pool.Poolable
> 
>  - Not thread-safe, but is fully reentrant.
> 
> A component whose methods are all fully reentrant is by definition
> thread-safe.

Not necessarily.

In my previous example, each method above can be fully reentrant--but
due to the specific ordering between method calls, it precludes ThreadSafe.

This is the difference between a method being reentrant and a Component
being reentrant.

The perfect case and point would be the XercesParser Component in Cocoon 2.
It implements the Parser interface, but it the Parser returned is "use-once"
only.  In order for a Component to be Poolable, the Component must be reusable.

Perhaps that is the word I should use: change "reentrant" to "reusable".
Mime
View raw message