You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Ju...@empolis.com on 2009/04/27 16:07:07 UTC
Concurrent execution of Invokes in in-memory processes
Hi (again ;-)
here's another question I posted some days ago. I changed the subject because
it actually not about extension activities (sorry, I should have done this
last time already), the discussion just started in a thread about them.
Any thoughts about this?
Regards,
Juergen.
-----Original Message-----
From: Juergen.Schumacher@empolis.com [mailto:Juergen.Schumacher@empolis.com]
Sent: Thursday, April 16, 2009 5:35 PM
To: dev@ode.apache.org
Subject: RE: Problem with flow and extension activities
Hi,
I'm moving this from user@ to dev@ ...
> -----Original Message-----
> From: Matthieu Riou [mailto:matthieu.riou@gmail.com]
> Sent: Wednesday, April 01, 2009 6:36 PM
> Subject: Re: Problem with flow and extension activities
>
> On Wed, Apr 1, 2009 at 2:56 AM, <Da...@empolis.com> wrote:
>
> > we took a look at the code and it seems that in the case of
> > <in-memory>true</in-memory> parallel execution is not supported at all.
> > - Was this implemented by design ?
>
> Yes, that's very likely. Although I wouldn't have any problem altering
> that design decision to offer a choice.
I played around a bit with this and for a start just changed the special handling of
in-memory processes in org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl.invokeIL(...):
if (_process.isInMemory()) {
// replaced code:
// invokeInMem(mexDao, partnerEpr, myRoleEpr, operation, supportedStyles, oneway);
invokePersisted(mexDao, partnerEpr, myRoleEpr, operation, supportedStyles);
} else {
invokePersisted(mexDao, partnerEpr, myRoleEpr, operation, supportedStyles);
}
... and it worked fine in our use case and it didn't make any notable difference in
your unit tests ("buildr test" in trunk). Is it really that simple?
Then I could provide a patch to make this configurable (globally in OdeConfigProperties?
Or per process in deploy.xml? Maybe better, because performance is probably better
with synchronous execution so it would make sense to enable this only for processes that
actually contain <flow>s).
Or are there any pitfalls with this approach?
Cheers,
Juergen.
RE: Concurrent execution of Invokes in in-memory processes
Posted by Ju...@empolis.com.
Hi,
> OK, I'll prepare the patch for this (next week, probably ;-).
Here it is: https://issues.apache.org/jira/browse/ODE-599
Cheers,
Juergen.
RE: Concurrent execution of Invokes in in-memory processes
Posted by Ju...@empolis.com.
Thanks for the feedback, Matthieu.
> > I played around a bit with this and for a start just changed the
> > special handling of in-memory processes in
> > org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl.invokeIL(...):
> > [...]
> > ... and it worked fine in our use case and it didn't make any notable
> > difference in your unit tests ("buildr test" in trunk). Is it really that simple?
> > Then I could provide a patch to make this configurable (globally in
> > OdeConfigProperties?
> > Or per process in deploy.xml? Maybe better, because performance is
> > probably better with synchronous execution so it would make sense to enable this only
> > for processes that actually contain <flow>s).
> >
> > Or are there any pitfalls with this approach?
>
> I don't think so, the code between the two methods is very similar
> anyway if you don't consider the transaction suspend in the in-mem case.
>
> I would also favor per-process configuration for this.
OK, I'll prepare the patch for this (next week, probably ;-).
Cheers,
Jürgen.
Re: Concurrent execution of Invokes in in-memory processes
Posted by Matthieu Riou <ma...@gmail.com>.
On Mon, Apr 27, 2009 at 7:07 AM, <Ju...@empolis.com> wrote:
> Hi (again ;-)
>
> here's another question I posted some days ago. I changed the subject
> because
> it actually not about extension activities (sorry, I should have done this
> last time already), the discussion just started in a thread about them.
>
> Any thoughts about this?
>
> Regards,
> Juergen.
>
> -----Original Message-----
> From: Juergen.Schumacher@empolis.com [mailto:
> Juergen.Schumacher@empolis.com]
> Sent: Thursday, April 16, 2009 5:35 PM
> To: dev@ode.apache.org
> Subject: RE: Problem with flow and extension activities
>
> Hi,
>
> I'm moving this from user@ to dev@ ...
>
> > -----Original Message-----
> > From: Matthieu Riou [mailto:matthieu.riou@gmail.com]
> > Sent: Wednesday, April 01, 2009 6:36 PM
> > Subject: Re: Problem with flow and extension activities
> >
> > On Wed, Apr 1, 2009 at 2:56 AM, <Da...@empolis.com> wrote:
> >
> > > we took a look at the code and it seems that in the case of
> > > <in-memory>true</in-memory> parallel execution is not supported at all.
> > > - Was this implemented by design ?
> >
> > Yes, that's very likely. Although I wouldn't have any problem altering
> > that design decision to offer a choice.
>
> I played around a bit with this and for a start just changed the special
> handling of
> in-memory processes in
> org.apache.ode.bpel.engine.PartnerLinkPartnerRoleImpl.invokeIL(...):
>
> if (_process.isInMemory()) {
> // replaced code:
> // invokeInMem(mexDao, partnerEpr, myRoleEpr, operation,
> supportedStyles, oneway);
> invokePersisted(mexDao, partnerEpr, myRoleEpr, operation,
> supportedStyles);
> } else {
> invokePersisted(mexDao, partnerEpr, myRoleEpr, operation,
> supportedStyles);
> }
>
> ... and it worked fine in our use case and it didn't make any notable
> difference in
> your unit tests ("buildr test" in trunk). Is it really that simple?
> Then I could provide a patch to make this configurable (globally in
> OdeConfigProperties?
> Or per process in deploy.xml? Maybe better, because performance is probably
> better
> with synchronous execution so it would make sense to enable this only for
> processes that
> actually contain <flow>s).
>
> Or are there any pitfalls with this approach?
>
I don't think so, the code between the two methods is very similar anyway if
you don't consider the transaction suspend in the in-mem case.
I would also favor per-process configuration for this.
Thanks,
Matthieu
>
> Cheers,
> Juergen.
>
>