On Mon, Apr 27, 2009 at 7:07 AM, <juergen.schumac...@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.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? > 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. > >
