-
1. Re: Abort long running method call
niox.nikospara.yahoo.com Apr 30, 2009 4:14 PM (in response to wachtda.scsi.gmx.ch)Does the query on the huge db return many results or an aggregation of them?
If it is an aggregation (eg the total amount of all orders of a person) you could utilize an MDB to run the query, while the SFSB returns immediately. Then the client will poll for the result. The outcome of the query (eg the total amount) could be written in a table together with a timestamp. A scheduled job will be cleaning old data from the table every once in a while.
If the query returns many results, then you probably have to implement it in a fundamentally different way. Thoughts: Have a servlet execute the query, based on parameters held by the SFSB. Build an asynchronous component on the client (Javascript) that will communicate with the servlet and render the results, when they are ready.
-
2. Re: Abort long running method call
gonorrhea May 1, 2009 11:34 PM (in response to wachtda.scsi.gmx.ch)So basically the client issues an HTTP GET request (via s:link or h:commandLink). Is there an action method fired as a result on a public method in the same SFSB?
If yes, perhaps the link action can fire a method on a different SFSB and start a new LRC.
Have you considered using stored procs or returning the result set to the view in chunks/pages so the user does not become impatient and move to another view?
-
3. Re: Abort long running method call
joblini May 2, 2009 6:25 AM (in response to wachtda.scsi.gmx.ch)A quick and dirty workaround would be to use conversationPropogation type="None" for the links. This would get around the concurrent access problem, but might cause other problems, depending on what is being stored in the conversation context.
Have you looked into
@Asynchronous
? There is an interesting if brief example in the Seam doc. The idea is to return control to the client immediately, and periodically check (using a4j:poll?) to see if the result is available.