Yes, I think that it’s important for
a Producer to know that the Consumers must serialize access to the “Portlet
groups”. From the implementation point of view this means that the code
is always invoked in a thread-safe manner, which definitely simplifies the
state management.
However I’d like to add that this
requirement must apply not only to event distribution, but also to blocking
action invocation. There can be a situation when the Consumer gets two simultaneous
requests to two different Portlets on the same page. In this case the Consumer
can invoke blocking actions concurrently on these Portlets only if they don’t
share the same groupID.
Regards,
Artem
From: Rich Thompson
[mailto:]
Sent: Wednesday, March 09, 2005
6:02 PM
To:
Subject: RE: [wsrp]
spec-2.0-draft-05: events and blocking actions
Agreed, the stated semantics is that multiple sets of
events may be sequentially distributed to any single portlet, but concurrent
distribution is prohibited. Concurrent distribution to different portlets (same
or different Producer) is allowed. If people think it would simply state
management, we could expand the nonconcurrent requirement to all portlets
sharing a groupID. Would that be valuable?
Rich
"Yossi Tamari"
<>
03/09/05 10:33 AM
To
<>
cc
Subject
RE: [wsrp] spec-2.0-draft-05: events and
blocking actions
Section
6.4.2.1 of the draft spec says: "While the Consumer MAY invoke
handleEvent() multiple times for any one portlet
while preparing to
gather markup, it MUST NOT invoke handleEvent() an
additional time while
the portlet is already processing an event for the
same End-User."
While it may not be stated, concurrent calls to
different producers or
to the same producer for different portlets are
allowed (and of course
also for the same portlet for different users).
Yossi.
-----Original Message-----
From: Subbu Allamaraju [mailto:]
Sent: Wednesday, March 09, 2005 5:10 PM
To:
Subject: Re: [wsrp] spec-2.0-draft-05: events and
blocking actions
>
> There hasn't been an agreement on blocking
semantics yet. I would be
> against any semantics beyond requiring all
event distribution (Note
that
> a Consumer could consider a Portlet which
hasn't responded in a timely
> manner to have finished, but failed to return
a response) to end
before
> starting the getMarkup step.
>
I agree that the consumer should wait for event
distribution to complete
before starting getMarkup step. I've a follow-up
question on the nature
of event distribution.
Can a consumer dispatch events concurrently to
various producers?
If the answer "yes" or "may
be", then another question to ask is whether
a consumer can dispatch two events (or two batches
of events) to a
producer for the same portlet? If the answer is
"yes", then it is going
to complicate state management for the consumer.
This would also make
the outcome less predictable. It would be hard to
debug for
portal/portlet developers.
Regards,
Subbu
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
