A few questions (pardon me if these were discussed before):
- What does concurrency mean here? For example, does this apply to *a*
consumer making concurrent requests to *several* producers (one request
per producer)?
- Since concurrency is an issue primarily for the consumer, would it not
be simpler to keep the producer unaware of this?
Regards,
Subbu
Eilon Reshef wrote:
> I second that. PerformBlockingX is a misnomer, since the operation
> itself doesn't block - rather we expect that the Consumer would block,
> but that's also not true as it may request portlets from other Producers
> in parallel. Hence, blocking doesn't seem like the right idiom in our
> concurrent environment.
>
> I think performInteraction and performConcurrentInteraction make much
> more sense (though I do think that interaction is better than action, as
> action implies some high-level (framework-oriented) concept which we
> don't necessarily provide or promote explicitly).
>
> -----Original Message-----
> *From:* Gil Tayar [mailto:]
> *Sent:* Wednesday, December 18, 2002 4:04 AM
> *To:*
> *Subject:* [wsrp-wsia] [I#201]
> performBlockingInteraction/performInteraction
>
> Issue: 201
> Status: Active
> Topic: interface
> Class: Minor_Technical
> Raised by: Andre Kramer
> Title: performBlockingInteraction/performInteraction
> Date Added: 18-Dec-2002
> Document Section: v0.85/5.3
> Description:
> performBlockingInteraction has proved very cumbersome to communicate
> and we very much want to encourage people to use it over
> performInteraction. And it still does not mirror JSR168's performAction.
> Resolution:
> "Review decision of last f2f based on pedantic feedback:-
> performAction and
> performConcurrentAction. Return structures
> BlockingInteractionResponse, InteractionResponse could become
> InteractionResponse (blocking inter-action) and ActionResponse
> (concurrent and blocking actions)."
