Re: [bpel4people] ISSUE BP-23: Title: (Re-)Evaluation and instantiationof logical people groups

[Ralf Mueller <ralf.mueller@oracle.com>]

Matthias,

"PROPOSAL: Instances of an LPG are per set of values for the parameters. 
Consequently, an LPG MUST be re-evaluated/re-resolved for each set of 
parameter values. For the same set of parameter values, it MAY be 
re-evaluated/re-resolved."

That sounds good for me.

Regards,
Ralf


Matthias Kloppmann wrote:
>
> Alessandro,
>
> I complete agree you here and that the draft text below is a bit 
> misleading. My *intention* certainly was to only enforce re-resolution 
> per "value set" of parameters that "has not been seen before", but not 
> mandate re-resolution for the same set. Then, "no parameters" are just 
> a special case where re-resolution is never mandated. In your example, 
> (re-) resolution would be required for 1) and for 2), and never after.
>
> So, here is a modified version of the text that reflects that more 
> appropriately:
>
> PROPOSAL: Instances of an LPG are per set of values for the 
> parameters. Consequently, an LPG MUST be re-evaluated/re-resolved for 
> each set of parameter values. For the same set of parameter values, 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.)
>
> Viele Grüße/Kind regards,
> -Matthias
> _Matthias Kloppmann_ <http://ehngsa.ibm.com/%7Eklm1/> 	
> 	E-Mail: 	_Matthias-Kloppmann@de.ibm.com_ 
> <mailto:Matthias-Kloppmann@de.ibm.com> 	
> 	Address: 	_IBM Deutschland Entwicklung GmbH_ 
> <http://www.ibm.com/de/entwicklung/> 	
> 	Vorsitzender des Aufsichtsrats: Martin Jetter
> IBM Distinguished Engineer 	
> 	Phone: 	+49 7031 16-3771 	(office) 	
> 	
> 	_Schönaicher Straße 220_ 
> <http://www.ibm.com/de/entwicklung/ueberuns/anfahrt_englisch.pdf> 	
> 	Geschäftsführung: Herbert Kircher
> Chief Architect, _Business Process Technology_ 
> <http://www.ibm.com/software/info/bpmsoa/> 	
> 	
> 	+49 7031 413110 	(home office) 	
> 	
> 	_71032 Böblingen_ <http://www.boeblingen.de/> 	
> 	Sitz der Gesellschaft: Böblingen
> Member, _Technical Expert Council CR_ 
> <http://w3.boeblingen.de.ibm.com/tec/> 	
> 	
> 	+49 160 9060 7676 	(mobile) 	
> 	
> 	_Germany_ <http://www.deutschland.de/> 	
> 	Registergericht: Amtsgericht Stuttgart, HRB 243294
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> /"Wisdom begins in wonder."/ – Socrates 	
> 	
> 	
> 	
>
>
>
>
>
> From: 	"Alessandro Triglia" <sandro@oss.com>
> To: 	Matthias Kloppmann/Germany/IBM@IBMDE, 
> <bpel4people@lists.oasis-open.org>
> Date: 	20.06.2008 05:39
> Subject: 	[bpel4people] ISSUE BP-23: Title: (Re-)Evaluation and 
> instantiation of logical people groups
>
>
> ------------------------------------------------------------------------
>
>
>
> 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
>
> ------------------------------------------------------------------------
> *From:* Luc Clement [mailto:luc.clement@activevos.com] *
> Sent:* Tuesday, June 10, 2008 10:27*
> To:* 'Matthias Kloppmann'; bpel4people@lists.oasis-open.org*
> Subject:* [bpel4people] BP-23: Title: (Re-)Evaluation and 
> instantiation of logical people groups
>
> 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
>