Its a little non-obvious but:
- create a keyed-object in the user session.
- the value is a Request + java Future for the result
- return immediately with a client-side redirect.
- while the client-side redirect is being handled, have a worker thread work on producing the answer.
By the time the client browser completes the redirect, getting the new page’s images, etc… the results are waiting for the user.
The alternative is to make the user painfully aware of how long the database is taking.
*Security Update (2011 Jan 24 ) :*
The key is vulnerable to attack since it is part of the response to the client, so
- Generate a random key
- Use user’s session id as a salt to create a SHA-1
- Store both the random key and the SHA-1 in the database with (
, ) as the primary key. (no separate indexing on just the RANDOMKEY.)
- Use both RANDOMKEY and the SHA-1 as the db lookup.
- Do not store the Session Id (avoid privacy issues with being able to corollate many entries to the same user)
- Expire the results after 2-3 days. ( Allows a daily batch job to do the clean up and avoids creating problems for user sessions that are semi-long lasting )
This method requires any hacker to know both the session id and the random key.
This approach may seem overkill, but a redirect-hardened mechanism can be used for situations like password resets.
A purely random result key is highly problematic because of the high (and untested) impact of any collisions. I pick so strongly on this point because:
- the developer is lulled into complacency about the actual collision rate
- the impact of a collisions is unknown and probably untested
- when/if a problem shows up:
- it will be in production
- the problem will be intermittent
- difficult to reproduce
- be disguised as another issue
- possibly cause data corruption
- possibly result in private user data being exposed
- difficult to retroactively correct.