Session Question

[Warren Bell]

I am debugging an app that has a session issue and I need to purposely corrupt the cookie the session is using on the client pc. The client is a Windows XP machine running Internet Explorer. I cannot find where the session cookie is kept. I have looked in C:\Documents and Settings\username\Cookies and C:\Documents and Settings\Warren\Local Settings\Temporary Internet Files. My app is using sessions. I am only aware of three different methods to keep track of a session, cookies, URL rewriting and hidden fields. I see the URL rewriting on the first request like I am suppose to. The URL is not rewritten afterwards, but my session is working on my app.

My questions are:

How is the session being kept track of on the client machine? And Where are session cookies located on a client running Windows XP and Internet Explorer?

Thanks,

Warren

[Bear Bibeault]

Temporary cookies -- those that go out of scope when a browser is closed -- are usually not persisted to the file system but are kept in browser memory.

[Warren Bell]

Is there a way to force the session to be stored on the file system or corupt the session that is stored in memory?

[Ben Souther]

What do you mean by corrupt it?

[Warren Bell]

Maybe I am going about this the wrong way. I have an app that uses a wireless scanning device as a client. Occasionally I get java.lang.IllegalStateException exceptions. I do invalidate the session in one part of my app. I believe something screwy is happening on the client side. Do you only get a java.lang.IllegalStateException when the session has been invalidated or do you also get it if my app cannot find the session that is returned from the client?

[Ben Souther]

See:
http://faq.javaranch.com/view?IllegalStateException

[Bear Bibeault]

Originally posted by Warren Bell:
Maybe I am going about this the wrong way.

You're going about it the wrong way.

As Ben pointed out (by pointing to the FAQ entry), an IllegalStateException has little to directly do with sessions and invalidation.

Most likely, your code just isn't dealing well with some situtation which may or may not be related to session invalidation.

The stack trace that accompanies the exception is your first hook into finding the errant code.
[ August 09, 2006: Message edited by: Bear Bibeault ]