Hi, sorry, I forgot to answer to the last mail. Let me do this first: AbstractSyncExtensionOperation is only for implementations that return (almost) immediately as they block the whole navigation thread (and due to the instance lock also all further threads). For potentially long-running transactions the AbstractAsyncExtensionOperation must be used. I don't know what you are doing with which DB connection, but they must be handled independent. I'm not sure if the WAITING kind of implementation can help here, as this is IMO needed to do something after an external event arrives. In the extension activity case (assuming you don't want to create structured activity) the external event should just complete the activity, which should be possible with the current implementation.
What exactly is the problem with the DB connection? Couldn't that be handled similar like the ExternalVariables implementation does? Thanks, Tammo On 31.05.2010 18:38, Milinda Pathirage wrote: > Hi Tammo and Rafal, > > We are going to try PICK activity like implementation to handle long running > extension activities. We are still working on the implementation. Will that > mechanism allow us to solve this database connection related issue. Will ODE > release db connection > when we go to WAITING like activity? > > Thanks > Milinda > 2010/5/24 Waruna Ranasinghe <[email protected]> > >> Hi Tammo and Rafal, >> >> I tried using AbstractAsyncExtensionOperation, but the database connection >> problem is still there. >> I think that we need to implement run method in >> AbstractSyncExtensionOperation >> to handle async operations. >> So that the db connections can be released when we need to. (i.e. after the >> service call to human task, we need to release the db connection.) >> WDYT? and any pointers? >> >> We are going to implement BPEL4People in ode's experimental branch (2.0) >> >> >> Thanks, >> Waruna >> >> >> 2010/5/22 Rafal Rusin <[email protected]> >> >>> 2010/5/22 Milinda Pathirage <[email protected]> >>> >>>> Hi Tammo and Rafal, >>>> >>>> We like to donate BPEL4People extension for ODE and continue >> development >>>> inside ODE. I'll start a separate thread on this. Also it'll be great >> if >>> we >>>> can get HISE incubator project into ODE project and complete the human >>> task >>>> implementation also inline with BPEL4People extension. AFAIK, we can >> move >>>> HISE to ODE. >>>> >>>> Our plan is to first implement BPEL4People with separate task engine >> and >>>> after that we can consider embeding task engine to ODE itself as >>> described >>>> in BPEL4People specification and implement the BPEL4People compilation >>>> things in ODE. >>>> >>>> WDYT? >>>> >>> >>> Sounds great. >>> It's really a good idea to combine efforts on Human Tasks. >>> HISE needs a separate distribution (war and osgi), because there is >>> interest >>> in using it as >>> standalone engine (and connect for example to CAMEL). >>> But I think it's a very good idea to include it in ODE sources (in >> trunk). >>> I think it will be good to have following structure: >>> trunk/ode-scheduler >>> trunk/ode-compiler >>> trunk/ode-axis2-war >>> trunk/ode-bpel4people >>> trunk/hise-services >>> trunk/hise-web (war assembly) >>> etc. >>> >>> This is, because ODE's goal is to have a set of small modules with >> minimal >>> dependencies, which can be assembled >>> (and reassembled) to construct full featured BPMS. ( >>> http://ode.apache.org/architectural-overview.html) >>> >>> In future we will have additional modules and assemblies for example to >>> support BPMN2, like >>> trunk/ode-bpmn2-war >>> >>> Thanks >>>> Milinda >>>> >>>> 2010/5/21 Tammo van Lessen <[email protected]> >>>> >>>>> Hi, >>>>> >>>>> I think it depends on the needs. If you need a quick solution, then >> I'd >>>>> go with Rafal's suggestion and implement in terms of a BPEL fragment. >>> If >>>>> you want to implement BPEL4People's people activities, the extension >>>>> mechanism is what you want, but it is still considered experimental. >>>>> AFAIK, long running extension activities have not yet been >> implemented >>>>> with it, but I'd appreciate any kind of comments to improve it so >> that >>>>> it fully supports this scenarios. We'd also appreciate a code >> donation >>>>> of the BPEL4People implementation of course (I'm pretty sure that it >>>>> needs additional extensions to ODE, besides the extension activity) >> ;) >>>>> >>>>> Which extension operation super class are you using? >>>>> >>>>> Best, >>>>> Tammo >>>>> >>>>> On 21.05.2010 07:25, Waruna Ranasinghe wrote: >>>>>> Hi Rafal, >>>>>> >>>>>> I'm trying to implement peopleActivity for BPEL4People as an BPEL >>>>> extension >>>>>> activity >>>>>> You may already aware of this and peopleActivity is a blocking >>>> activity. >>>>>> >>>>>> It is quite convenient to use an extension activity rather than a >>>>> separate >>>>>> process since we need to correlate messages and etc... >>>>>> >>>>>> So do you think that I should drop the extension and go for a >>> separate >>>>>> process? >>>>>> WDYT? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Waruna >>>>>> >>>>>> On 21 May 2010 10:19, Rafal Rusin <[email protected]> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> is it possible to decompose your extension activity into a >> process, >>>>> which >>>>>>> will wait for few hours and invoke only >>>>>>> quick parts of code? >>>>>>> >>>>>>> On 12 May 2010 23:51, Waruna Ranasinghe <[email protected]> >>> wrote: >>>>>>>> Hi devs, >>>>>>>> >>>>>>>> I have been writing a bpel extension activity which does an >>> external >>>>>>> service >>>>>>>> call and waits for the response. >>>>>>>> The activity itself is a blocking activity. It may have to wait >> for >>>>> hours >>>>>>> to >>>>>>>> get the response, so that it may take hours to complete the >>> activity. >>>>>>>> >>>>>>>> Problem is, If I create few instances from this process, after >>>> sometime >>>>>>> it >>>>>>>> will complain about getting database connections saying that "No >>>>>>>> ManagedConnections available within configured blocking timeout ( >>>> 30000 >>>>>>> [ms] >>>>>>>> ) for pool >>>>>>>> >>>> org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor" >>>>>>>> >>>>>>>> I think this happens due to the Extension activity which takes >>> hours >>>> to >>>>>>> get >>>>>>>> completed, so that the db connection also holds on to it until >> the >>>>>>> activity >>>>>>>> get completed >>>>>>>> >>>>>>>> Therefore, If we can close the connection after external service >>>> call, >>>>> I >>>>>>>> think we can fix this issue. >>>>>>>> >>>>>>>> Any body aware of how to close the db connection within an >>> extension >>>>>>>> activity or any other work around?? >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Waruna >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ----------------------------------------------------- >>>>>>>> Regards, >>>>>>>> Waruna Ranasinghe >>>>>>>> BLOG: http://warunapw.blogspot.com >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Rafał Rusin >>>>>>> http://rrusin.blogspot.com >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Tammo van Lessen - http://www.taval.de >>>>> >>>> >>>> >>>> >>>> -- >>>> Milinda Pathirage >>>> Senior Software Engineer & Product Manager WSO2 BPS; >> http://wso2.org/bps >>>> WSO2 <http://wso2.org/bps%0AWSO2> Inc.; http://wso2.com >>>> E-mail: [email protected], [email protected] >>>> Web: http://mpathirage.com >>>> Blog: http://blog.mpathirage.com >>>> >>> >>> >>> >>> -- >>> Regards, >>> Rafał Rusin >>> http://rrusin.blogspot.com >>> >> >> >> >> -- >> ----------------------------------------------------- >> Regards, >> Waruna Ranasinghe >> BLOG: http://warunapw.blogspot.com >> > > > -- Tammo van Lessen - http://www.taval.de
