I've read that SESSION VARIABLES are a "bad" thing. And I do understand the thought behind it, since it would be problomatic in a Server Farm environment.  However, I have the following questions:

1) Is there any alternative offered by the DNN Core to SESSION VARIABLES? I looked into User Personalization, but I don't want the data saved permanently for the user, only temporarily for the current login session.
2) Does DNN (Version 6) create any Unique ID at the time of Login that I can use to label saved data in a custom table on the SQL Server? Something that gets tossed immediately at time of Logout.

The reason I ask #2, is because I found that if I store some data in a SESSION VARIABLE, if a user logs out, and logs back in, the SESSION VARIABLE data remains. I added a SESSION.ABANDON() command to the LogOff routine which fixed this, but I assume that I would not be able to use a SESSION_ID number, because obviously Logging out of DNN doesn't reset the session.

Help!  :-)

Wes,
   Thanks for your input. :-) This is basically why I am looking for alternatives. Right now SESSION VARIABLES are working, however if the Module I am creating is installed on a WebFarm...then I'll have trouble. I am trying to head off the problem before it becomes one.

Well yes, that what I was talking about doing, using the DB to store the data.  However, without somehow "marking" the saved data with some sort of UniqueID that is used just for that current login, there is no easy way to know what data to then delete later. That is what I need, the ability to store data but just for the current login session. The problem with Cookies and saving data in the DB directly, is that the data persists after the person logs out.

The best solution I think is to store the data in the database, but without a unique login-specific ID...there is no way for me to expunge the data after a user logs out. The only thing I might be able to try is stamping the DATETIME to any records and have my module check periodically and delete "expired" data (which would simply be some sort of timeout/TTL value I suppose. Or if possible, check if the owner of said data is still actively logged in and delete the stored data if not. This way the data doesn't accumulate in the database.  But the latter idea would only work if the DNN site in question has login tracking activated.

It would have been much easier if the DNN Authentication Provider created a unique Login-Session ID that is valid for that current login only, which could be retrieved and used by any module. But I guess that is no such thing and I just have to either come up with my own method, or just stick with my SESSION VARIABLES and cross my fingers no one installs it on a server farm.