Concurrent execution of Invokes in in-memory processes

[Juergen.Schumacher]

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.schumac...@empolis.com [mailto:juergen.schumac...@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.r...@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, <daniel.stu...@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.