ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthick Sankarachary <sankarach...@intalio.com>
Subject Re: [VOTE] Include event_handler_1x.patch into ODE-1.X
Date Fri, 06 Nov 2009 21:27:25 GMT
Rafal,

Here's the real reason why process model compatibility is such a thorny
problem. The fact is that we serialize and persist the process instance
state, which comprises instances of the process object model, every time the
process instance goes into a wait mode and has to be  dehydrated. If we
rehydrate the state of a process instance using a process object model that
is not compatible (i.e., whose classes no longer match the ones used at the
time of dehydration), then chances are the instance will fail, unless we
take measures to protect against the compatibility issue. The bottomline is
that it is hard to write a migration script (XML-based or not) that will
"fix" the process state for you. That was the motivation for forking
multiple versions of the process object model in the ODE trunk.

To simplify your sanity check, I would write a getter for the _replyRid
field, which in turn would initialize it to an empty hash, if it happens to
be null, which is what it'll be if you're dealing with an older instance.

Best Regards,
Karthick Sankarachary


On Fri, Nov 6, 2009 at 1:07 PM, Rafal Rusin <rafal.rusin@gmail.com> wrote:

> 2009/11/6 Karthick Sankarachary <sankarachary@intalio.com>:
> > Rafal,
> >
> > To mitigate against any potential compatibility issues, I suggest that
> you
> > write the OutstandingRequestManager such that it works even if the new
> field
> > that you added (i.e. _replyRid) has not been initialized. Specifically,
> if
> > that field is null you probably want to assume that there's no reply
> > corresponding to the entry in question. This sanity check will help
> ensure
> > that instances started prior to the upgrade do not break down due to this
> > change in the process model.
>
> OK, this sanity check looks easy to do. I can add that. But handling
> all potentially broken cases in modified OutstandingRequestManager or
> adding new class OutstandingRequestManager2 + iffs around code, would
> be bad I think.
>
> What I want to achieve with this vote is to see committers' and users'
> opinions on backward compatibility for instances. Because I don't
> believe that users care much for upgrading ODE from 1.3 to 1.4 with
> holding their old binary instances.
> As for me, I prefer more clean code, which is quite messy in some
> places for now in ODE. And as for migration, I think it may be solved
> some time in future by implementing export/import to/from xml
> mechanism.
> Similar thing is for ODE trunk. There are two packages for runtimes v1
> and v2. I think it's a very bad solution for providing backward
> compatibility, because it's a full duplication of code. I would prefer
> to not provide backward compatibility and have only one runtime.
>
> Well, if your opinion is opposite, please don't hesitate to vote -1.
> It's just a simple voting, no offense at all.
>
> Regards,
> --
> RafaƂ Rusin
> http://www.touk.pl
> http://top.touk.pl
> http://people.apache.org/~rr/ <http://people.apache.org/%7Err/>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message