Flyweight pattern (was: Ode Performance: Round I)

[Alex Boisvert <bo...@intalio.com>]

On 6/6/07, Assaf Arkin <ar...@intalio.com> 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?

alex

Re: Flyweight pattern (was: Ode Performance: Round I)

[Matthieu Riou <ma...@gmail.com>]

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 <ar...@intalio.com> wrote:
>
> On 6/6/07, Alex Boisvert <bo...@intalio.com> wrote:
> >
> > On 6/6/07, Assaf Arkin <ar...@intalio.com> 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
> >
>

Re: Flyweight pattern (was: Ode Performance: Round I)

[Assaf Arkin <ar...@intalio.com>]

On 6/6/07, Alex Boisvert <bo...@intalio.com> wrote:
>
> On 6/6/07, Assaf Arkin <ar...@intalio.com> 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
>