You use the phase "user logs out" so I assume people have accounts on this service. There are a number of ideas on the table already with regards to sessioning, storing only session IDs on client cookies and using server storage for the lists.

I have always tried to associate the 'timeout' for each persion (session) separately and base it off of the inter-message delay. So, anyone who is working on a list will lose the list if they leave it unfinished for a day (e.g.). Depending on the nature of these lists, you might also want to use a 'list' key in addition to a session key, allowing the same visitor to manage multiple lists.

Another thing we found when building sites for clients is that even within six months the traffic patterns on their sites would change (often increase) and hence it was highly adviseable to link that 'timeout' to an actual resource parameter.

For example, the 'timeout' would vary b/w 1 hour, 6 hours, 12 hours, 24 hours; based on a function that took into consideration the disk space available, the number of new lists being created over the past three hours, the 'authority' level of the user, and the calculated decay rate of information (how many disk space will be freed up in the next three hours). Once a time out is assigned, and the user is told about it, it shouldn't change.

If you have a large number of users hitting the site, specially if users can sign on automatically, this measure is a semi-decent measure against running out of resources because of heavy use (or malicious use).

And of course, move any finished lists to a separate dedicated data storage.

-- termix