Oh well - back to the drawing board :)
On Tue, Mar 22, 2011 at 3:12 PM, Tammo van Lessen <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 >
