Abort long running method call

[wachtda.scsi.gmx.ch]

I have some huge problem with a long running method call (in a SFSB) which should be aborted:

1.) The user calls the method which makes a jpa query of a huge database
2.) The user has no patience to wait for the respond and clicks a link to another view

Because the method call isn't finished yet, the user gets a org.jboss.seam.core.LockTimeoutException.
(could not acquire lock on @Synchronized component)

What can I do, to abort the method call?
I don't like to raise the Timeout and i need this in a session scoped bean!
Because the user don't want to see the response, the response is obsolete and shoul not result in an exception.
Any hints?

Thanks for helping

[niox.nikospara.yahoo.com]

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.

[gonorrhea]

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?

[joblini]

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.