-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 9/17/2009 4:56 AM, Mark Thomas wrote:
> atroiano wrote:
>>
>> Is it possible?
>
> The way you describe? No.
+1
> If you want this then you have a couple of options:
> a) Do what Chris said and pass state back and forth in the request/response
More specifically, architect your session such that a few pieces of
information can re-create the session state, rather than having to
encode /all/ session state in the URL (otherwise, you'd never need the
session, now, would you?).
Here is a concrete example: we deliver questionnaires on-line to
respondents. If their session times out in the middle of taking a
questionnaire, we want them to be able to resume right where they were.
We put the "id" of the questionnaire they are taking right into the URLs
of any links, and into any forms they can submit (answering a question
submits a form, so usually we're talking about POST parameters here).
If the session times out, the next request (after successful
authentication, that is) will have nothing available but the
questionnaire id. The code that manages the questionnaire will look for
the session objects, and, not finding them, will take the id from the
request, reconstruct everything in the session necessary to continue the
questionnaire in-progress (because the state of the /questionnaire/, not
the session itself, is stored in our database), and then resume the
questionnaire.
So, although we have a bunch of information stored in the session in
order to deliver the questionnaire quickly, the disappearance of the
data in the session is tolerable: we simply recover by re-building the
session information given that one special request parameter.
Of course, you have to architect your application to work this way.
There is no special configuration option for Tomcat (nor any other app
server for that matter) that can simple recover your session for you
after it expires.
> b) Buy more memory and have longer session expiration times
> c) Look into using the persistent session manager
There's another option if you want drop-in session recovery. It's a
giant hack, won't work except under the best of circumstances, and
probably counts as bad design (it IS a giant hack), but you could:
1. Make sure everything in your session is Serializable
(always a good thing)
2. Make sure every URL you use is run through response.encodeURL()
(including form actions!)
3. Write a filter that does the following:
a. Wraps the response in a special subclass of
HttpServletResponseWrapper (see below)
b. Checks for the presence of a session, then checks the session
for a magic attribute (say, "SESSION_CONFIGURED" or whatever)
c. If the magic attribute does not exist, recovers the session
(see below)
d. Calls the next filter in the chain
4. Write an HttpServletResponseWrapper that overrides encodeURL
and encodeRedirectURL to do the following:
a. Serialize all session attributes to a GzipOutputStream,
then encrypt them using some decent encryption algorithm
(such as 3DES, Blowfish, etc.), then add this data to the
URL in a unique parameter like SESSION or whatever.
Session recovery is simple: just decrypt the SESSION request parameter,
deserialize the data, and shove it into the session. Instant session
recovery.
Here are some potential problems:
* See #1 and #2 above
* If you have a lot of session data, you may exceed the URL length limit
* Performance will suffer due to all that encryption being done for
every URL you generate
But, if you have small session data, this might work.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqyZVcACgkQ9CaO5/Lv0PB8QgCfVfRlAYQfmq/OTwXrF5JNdCOA
Rv0AnRHcv6bA6B+A+bGl8/Dpb2RDmepr
=xUe9
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
