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 >> >
