Agreed - just need to use a reference that remains stable across compilations, but still uniquely identifies the relevant node in the DAG.
Regards Gary On Tue, Mar 22, 2011 at 3:43 PM, Shivaraj Tenginakai <tshiva...@gmail.com> wrote: > Way I have seen this implemented is that we need to distinguish > between user state and ode state. ODE state represents the structure > of the DAG while the user state represents the value of the variables > and the position in the DAG . > > If we can achieve a clean separation between ODE state and user state, > then future evolution would become easy. > > Shivaraj > > > On Tue, Mar 22, 2011 at 8:42 PM, Tammo van Lessen <tvanles...@gmail.com> > wrote: >> Hi Shivaraj, hi Gary, >> >> yes and no: first, when compiling the process model, each OModel node >> contains a unique ID and this is currently a GUID. Thus, even if the >> BPEL code is unchanged, the OModel nodes will have different IDs after >> compilation. Second, these IDs are used when serializing the runtime >> state. The JACOB soup keeps references to the OModel. When serializing >> the state, these references are replaced by placeholder objects that >> store the GUID of the original node to avoid serializing the whole >> OModel object graph. This is an optimization to save time and space. >> >> Tammo >> >> On 22.03.2011 15:35, Gary Brown wrote: >>> Hi Shivaraj >>> >>> As far as I am aware this issue is not related to state - only the >>> static representation of the business process. The OModel simply >>> represents a binary compiled version of the BPEL process definition. >>> So all I am suggesting is rather than store the binary version, we >>> store the xml version, compile on first load, and the end result is an >>> up-to-date OModel, regardless of the age of the process instance. >>> >>> Regards >>> Gary >>> >>> On Tue, Mar 22, 2011 at 12:34 PM, Shivaraj Tenginakai >>> <tshiva...@gmail.com> wrote: >>>> Gary, >>>> >>>> Would it be possible to distinguish between execution optimization and >>>> state? As long as state information can be derived from one version to >>>> another, it should be fine to recompile (to achieve execution >>>> optimization). >>>> >>>> Thanks, >>>> >>>> Shivaraj >>>> >>>> >>>> On Tue, Mar 22, 2011 at 3:40 PM, Gary Brown <g...@pi4tech.com> wrote: >>>>> As discussed on the call today, we need a way to overcome the >>>>> constraints of the serialized OModel which is produced when compiling >>>>> the BPEL process. >>>>> >>>>> Although a more flexible serialization mechanism may provide a >>>>> solution, as was also discussed, there will be cases where additional >>>>> logic would be required to determine how an older representation >>>>> should be evolved into a new representation. >>>>> >>>>> Another approach would be to use the BPEL process (xml) directly, so >>>>> rather than using a binary representation compiled in advance, the >>>>> runtime would simply load the BPEL DOM. >>>>> >>>>> If this required a change to the internal OModel mechanism, then it >>>>> may be more work than the proposed dynamic OModel idea, however if we >>>>> simply took the approach of "compile on load", then we get away from >>>>> the issue, which is the persisted serialized form. We also no longer >>>>> require any specific migration logic to move from older versions of >>>>> the persisted representation (dynamic or not). >>>>> >>>>> So we could keep the existing OModel format, which can evolve as >>>>> required as long as the compiler is kept in step, and we should no >>>>> longer have any issues with long running processes. >>>>> >>>>> This change could be introduced into the current 1.3.x trunk without >>>>> any backward compatibility issues. >>>>> >>>>> The only trade off is the speed difference between (1) loading the >>>>> compiled representation versus (2) parsing the XML & compiling the >>>>> BPEL process. If this would need to be performed multiple times in the >>>>> same runtime, then a hash of the process could be used to cache the >>>>> compiled version so this is only performed once per process >>>>> definition. >>>>> >>>>> Thoughts? >>>>> >>>>> Regards >>>>> Gary >>>>> >>>> >> >> -- >> Tammo van Lessen - http://www.taval.de >> >
