On Mon, Apr 27, 2009 at 7:07 AM, <[email protected]> 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: [email protected] [mailto: > [email protected]] > Sent: Thursday, April 16, 2009 5:35 PM > To: [email protected] > Subject: RE: Problem with flow and extension activities > > Hi, > > I'm moving this from user@ to dev@ ... > > > -----Original Message----- > > From: Matthieu Riou [mailto:[email protected]] > > 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, <[email protected]> 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. > >
