Any restriction on concurrency is going to
cost in a truly distributed environment so I definitely favor not introducing such
serializations.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 09 March 2005 16:02
To: wsrp@lists.oasis-open.org
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"
<yossi@giloventures.com>
03/09/05 10:33 AM
|
To
|
<wsrp@lists.oasis-open.org>
|
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:subbu@bea.com]
Sent: Wednesday, March 09, 2005 5:10 PM
To: wsrp@lists.oasis-open.org
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:
wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
wsrp-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail:
wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
wsrp-help@lists.oasis-open.org