|
Here are some
thoughts about this issue and the proposed resolution.
The
distinction between the two cases ("function called with same parameters as last
time" and "function called with different parameters") seems artificial to
me.
On one hand,
if the standard does not mandate reevaluation of the people query in the
"same parameters" case, and if the underlying data changes, two different
processors may behave very differently when presented with two identical
scenarios (including timing). The text proposed below implies that a
process that lasts several days is allowed to ignore changes
in the underlying people data that occur over a period of
multiple days, and I don't think this is a desirable behavior in
general.
On the other
hand, if the standard mandates reevaluation of the people query in the
"different parameters" case, this may adversely affect performance.
Caching may be useful both in the case of "same parameters as last time" and in
the case of "different parameters". For example, a process
could contain the following (unrolled) sequence of
invocations:
1)
regionalSalesPeople("Wales")
2) regionalSalesPeople("Sussex")
3)
regionalSalesPeople("Wales")
4) regionalSalesPeople("Sussex")
5)
regionalSalesPeople("Wales")
6) regionalSalesPeople("Sussex")
and in a case like this, a processor could
remember the result of query #1 and reuse it (avoiding an expensive
reevaluation) for query #3 and #5, and do the same for query #2 #4 and #6
respectively. There is no reason that caching should be limited to a
single set of parameters (and corresponding result) being remembered by the
processor. I would, in fact, consider this case as the general case, and
the "same parameters as last time" case as being a special case of a sequence of
invocations. I regard caching as being a pure internal optimization tactic
used by the processor, whenever the processor deems that the result of a query
will be the same as one of those that occurred in the past, for a given set of
parameters, and which it still remembers. When a processor knows
or suspects that a query would now produce a result different from the
one it produced the last time it was invoked with a given set of
parameters, the processor should reevaluate the query, and should not
reuse the old results (and therefore the standard should be worded in such a way
to disallow the reuse of the old results in this case; the statement
proposed below does not do this).
Summarizing, I think that the "MAY" in
the second sentence below is too weak (it may cause undesirable visible
behavior) and the "MUST" in the first sentence is too strong (it prevents
certain optimizations). My suggestion is to state that a people
query invoked by a processor MUST return a result that is correct at the time of
the invocation (or something like this), with no distinction between the
"same parameters as last time" case and the "different parameters" case.
This formulation would allow a processor to use caching whenever it
believes that the result hasn't changed since the last invocation of the query
with a particular set of parameters which it still remembers, and
would require evaluation (or reevaluation) of the query in all the other
cases.
Alessandro Triglia
OSS Nokalva
Assigned: http://www.osoa.org/jira/browse/BP-23
From: Matthias
Kloppmann [mailto:matthias-kloppmann@de.ibm.com]
Sent: Tuesday,
June 10, 2008 10:22
To:
bpel4people@lists.oasis-open.org
Subject: [bpel4people] NEW ISSUE:
(Re-)Evaluation and instantiation of logical people
groups
TARGET:
BPEL4People Working Draft 02
DESCRIPTION: When
are logical people groups re-evaluated, in particular for parameterized
logical people groups.
Resolution of
logical people groups happens on several occasions: When referenced from an
htd:from clause, or when referenced from a getLogicalPeopleGroup XPath
function. When accessed the first time through either means, a logical people
group is evaluated. In a BPEL4People process, the same logical people group
may be referenced again, possibly with a different set of arguments values.
The specification needs to state what the rules are for re-evaluating
(re-resolving) the logical people group.
PROPOSAL:
Instances of an LPG are per set of values for the parameters. Consequently,
when arguments of parameters are changed between referencing an LPG the first
time and the second time, it MUST be re-evaluated/re-resolved. When parameters
are not changed between referencing an LPG the first time and the second time,
it MAY be re-evaluated/re-resolved.
(Motivation: Allow
a modeler to reuse a logical people group, e.g., in a loop, with different
bindings -- the example we discussed was regionalSalesPeople("Wales"),
regionalSalesPeople("Sussex") -- you want to be sure the second one does not
retrieve the former result, unless they are really the same. Allow in
implementation for caching: When regionalSalesPeople("Wales") is called
several times, the result could be cached, because re-resolution is not
mandated.)
Regards,
Matthias
|