The links provided to Marty Hall's book info have some valid information, but they book is not good, Marty Hall intentionally avoids anything useful in all but the most trivial applications. Also the book is QUITE old... That said, the sections on sessions shoudl be useful...
You may want to just limit your form's memory to cookies... which you can handle with Javascript...
I don't like to use sessions to store ANY information until I know the user is valid... Cookies will remember across session too, and server restarts, etc. so they are better for login page memory...
For form memory for internal forms, once the user has logged in, you have DB, XML, etc. that you can leverage... obviously DB is the best choice if you are using one... only resort to text files such as XML if you can't use a DB...
Also, once the user logs in you can store their user name etc. in sessions, but be careful... too many developers get carried away with session information... its like taking them to the candy store when they're 8 and letting them run loose... they want to save everything...
The problem is knowing when the data is safe to remove from the session to prevent a memory leak type situation... I know it isn't a true memory leak, as the session will "hopefully" be invalidated and the memory recovered... BUT imagine a system that tracks 20KB of information about each user in the session, 20KB isn't much these days... NOW a system that only tracks 5KB... how many more concurrent users will the second system be able to support before resources become an issue....
This is a serious problem for many developers... many of the best make serious errors here and the resultant systems can cost the customer 100's of thousands in additional hardware costs to cluster support for more users... and 100's of K$ more in development costs to built the clustering support into the application....
Keep It Simple XXXXXX I don't like to use the other S word in that... Smart people don't always act very smart, but that doesn't make them less intelligent... perhaps less wise....but not less intelligent...
Anyway, I don't know what "other" reasons you have, but typically you DON'T CARE who the user is until they login... and thus cookies are better for non-logged in users... put the memory restriction on the guest until they validate themselves...
If you DO resort to using sessions for non-logged in users, be careful to use them wisely, and clear unused data as soon as it is no longer valid...
Also, session stored data is difficult to update "on the fly" ... what I mean is that if you store user preferences, etc. in the session when they login, then they go to the preferences page and change them, you have to manually update them for that user... BUT what if a user's preferences effect someone else's viewing experience... if the preferences change, you have no easy way to notify the other user's sessions that they need to be updated too...
Actual case I ran into recently when reviewing code written by oneof my developers...
OK, good luck...