Need to Return immediately and commit the App Module on a different thread

Question

I have an action that I want to return fast (immediately) but the server processing takes longer than acceptable. The results of the operation don't matter to the page submitting it and I want it to be able to navigate away even if the operation is not complete. I want to either be able to send a non-blocking server event from the browser or on the server side start a new thread that performs the operation allowing the original thread to return immediately. The new thread would need access to an Application Module in order to commit data. How would I go about accomplishing this?
Some thoughts
I've tried creating a ConcurrentLinkedQueue and putting the DataControl on the que, then in the other thread I pull it off the que, process and commit the data. This works unless the page is navigated away from. Then calling dc.getApplicationModule(); returns null.
I thought about using createRootApplicationModule in the new thread (since the new thread has no context) but don't know how that would work
This is the code in the run method of the new thread. In this example, I'm adding data to the app module in the original thread and committing the data in a new thread.
(like I said, it works most of the time.)
Object[] req = (Object[])que.poll();
DCDataControl dc = (DCDataControl)req[0];
try{
ApplicationModule am = dc.getApplicationModule();
if (am != null){
am.getTransaction().commit();
} else{
System.out.println("AM:null unable to commit ");
} catch (Exception e){
e.printStackTrace();
finally{
if (dc!= null){ dc.resetState();} // release app module
}

Answer 1

Thanks for the replies. I am aware of the inherent risks of running a separate thread within a managed container.
The use case is a performance logging operation. We have a internal web app used by a network of franchises with over 1000 users. We log response time and performances statistics to the database. When the user clicks to navigate or commit data, the response time that the user experiences is logged after the page has fully rendered either through a PPR or a full submit. This is done by submitting ADFCustomEvent from javascript on the page after rendering is complete.. The event sends up the time difference from when the user first clicked to when the page was fully rendered. This information is then merged with logged events stored on the users Session that shows the name and response time of every query that was executed during the previous request. Depending on the page this could be up to half dozen to a dozen or more queries. The logging operation as experienced by the browser is generally fast (<200ms) but sometimes can be as long as a second or more when the database gets busy. A half second is too long as makes the app appear sluggish if the user can't type or click immediately after the page has finished rendering. The logged data is aggregated so we know exactly how much of the page load was due to a slow browser/network, how much was database time, webservice call time, etc... If it's due to a slow database we can drill down and see which query is the culprit. These performance metrics are critical to operations and are charted throughout the day so we know exactly what our users are experiencing. All of our users use a custom firefox client that we control. Using this logging framework we were able to determine that upgrading to a Firefox 4.0 based client cut browser render time by more than half a second on average. We can also tell what type of hardware the user is running so can place the blame for poor performance where appropriate. We have determined that pages render considerably faster on Windows 7 than on Windows 98 with the same hardware. We are moving the logging tables off of our exadata database to a separate box to remove that load from the application database. Since we expect the other database not to perform as well we don't want it to affect the user experience, hence the need to log asynchronously. I would like to put the data on a queue and have a background daemon process read from the queue and commit to the database. I would like the daemon thread to be able to use BC components. I would prefer not to resort to using a web service because of the inherent overhead. The logging operation is not a long operation but is of high frequency so should be as streamlined as possible. The load is spread over 6 servers with 4 JVM's each (24 weblogic instances). I know it's possible to use BC components from a plain Servlet (which runs on it's own thread) so what I want is to have something like a servlet thread that loops forever processing my logging queue.
One other method I am investigating is using my own non-blocking ajax call that callls a servlet to perform the logging. I will need to pull out the timestamp contained within a client side ADF component along with the pages ctrl-state variable that is included with every ADF request as it uses this as the key to get to the data on the session. ADF really needs a non-blocking ADFCustomEvent for this type of request. (send and don't care about the response)
The client component with the server listener looks like this
<af:outputText value="#{pageFlowScope.perfClientTS}" visible="false"
id="perfClientTSField" clientComponent="true">
<af:serverListener type="logPerfData" method="#{perfLog.logPerfDataAction}"/>
</af:outputText>
The script that queues the ajax call after the page loads looks like this
AdfCustomEvent.queue(perfClientTSField, "logPerfData", {
typeId : typeId,
subTypeId : subTypeId,
responseTime1 : new String(responseTime1),
responseTime2 : new String(responseTime2),
openedVia: via
true);
I also tried calling the noResponseExpected() method on the event before queuing it but it still blocked the UI and caused an additional side effect in that the client sent two ajax requests instead of one. It somehow thought something on the client side needed to be synced with the server.
email me and I can send a doc with more details about how our performance logging framework works.
Edited by: Don Kleppinger on Mar 14, 2012 2:52 PM