Yeah, it's a very nice idea but I think it needs more thoughts as there are a few difficulties in reusing some of the states. For example if you have a date in one of the activities (which we do) the state is always going to be different. Counters (like in loops) also make our lives harder.
Another issue is how we identify that 2 states are equal. We could come up with some hash but then the code becomes pretty fragile. We'd have to implement hashes for every activity, which isn't too hard. But say somebody adds an attribute in one activity and forget to update the hash calculation. We end up with a real mess. And building tests to detect those errors is very hard as well. So as Assaf said, in theory it's a very nice idea. Practically there are quite a few non trivial problems to overcome. On 6/6/07, Assaf Arkin <[EMAIL PROTECTED]> wrote:
On 6/6/07, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > On 6/6/07, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > > > It's persistence processes where we should find strategies to improve > > > > performance/scalability by reducing serialization cost. > > > > > > > > > Yep, the flyweight pattern <http://c2.com/cgi/wiki?FlyweightPattern> > > would > > > be most efficient here (also suggested by Matthieu in different words) > > > > That only works if you have a finite number of states. > > > > Don't we have a finite number of persistent states for a given process > definition, without taking into account variables+partnerlinks? In theory, if you don't use event handlers and never store any non-variable data. ActivityRecovery definitely violates the second principle, introducing infinite number of states after failure. It becomes worse if you want to inspect the process state directly, then you need activity start/end times, loop counters, etc. Assaf alex >
