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.
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?
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.