1 Reply Latest reply on Mar 23, 2013 11:08 AM by Timo Hahn

    What happens to AM instances used by asynchronous threads


      We have a long running process inside an AM, that calls pl/sql packages. Sometimes, this is causing http connection timeout depending on the volume of data it is processing. While we can increase the timeout, we are exploring other options. One that we're planning to spawn a thread in the backing bean, and invoke the AM method binding inside the thread. And have a polling component on the UI that keeps checking the status of the process. If you guys have done it before, please share your experiences and insights. Please help us with the following questions:

      1) When we spawn a thread that uses an AM instance - will it still be managed by ADF or completely moves out of ADF control ?

      2) In our case we spawn a thread and return control back to the UI. So obviously the http connection / HttpServletResponse will be closed immediately. Does this also trigger ADF to forcefully reclaim the AM ? or ADF considers it as busy and not-passivate/release until thread completes ?

      3) Precisely at what point in time, AM gets released? is it upon closure of http/servlet connection ? or upon completion of am method calls ?

      4) Upon thread completion, do we need to take care of releasing it back to pool or ADF will do it automatically ?

      5) Does ADF transaction management work fine with thread scenarios ?

      4) What happens, If another request comes from the same user? does it get a different am instance to cater that request ? Even if it gets a different am instance, it might represent an invalid state, because the previously initiated process could still be running.

      Your help is greatly appreciated.

      Have a good weekend.

      Thank you
        • 1. Re: What happens to AM instances used by asynchronous threads
          Timo Hahn
          If you spawn a new thread to do work, you should use another application module than the one you use for the UI. The way I do this is to call a method in the am which then spanws the new thread which then gets a new root application module and the thread uses this ma exclusivly. All changes done in the thread are part of the transaction of the am used in the thread. There can't be any communication with the transaction from the am used in the ui. The ui only can react on changes done in tables in the db. The spawned thread uses a semaphore which only allows one execution of the thread until the thread has done its work. Here you have to be careful if your app runs in a cluster environment. In this case the semaphore has to be stored in the db or an a shared file system.

          One other way to do this (more easily) is to implement hte log running process as an asynchronous web service. then you call this service from your UI and let the service do the work. Via the callback you get notified once the service has finished.

          1 person found this helpful