That means to blow out and destroy the session variables - yes, that looks to be reset of session.
It might fix the overlapping issue, but doing that will erase all session that currently exists for all users.
In other words, it might fix the overlapping problem, but also going to re-set any user on the web site. I think a better solution would be to re-start the web server.
Keep in mind that if your hosting has switched to some type of cloud based "server farm", then in-memory session can't really be used anymore, since when one page is requested, it could be dished out by any of 20 existing web servers, and those 20 existing web servers don't share memory, and hence don't share session. Of course with SQL server based session management, then they all hit and use the sql server database for session, so it will work just fine.
I have always found when nasty session issues crop up? I just dump memory based session(), and simple turn on and add SQL server based session management. Once I done this, then session() becomes rock solid, never fails, and can even survive a app-pool re-start (which can OFTEN occur if some code on the web site errors out, and will cause a app-pool re-start). Have not tested, but even a web site re-start will still return existing session.
In addition to the above, if you using a server farm, or load balancing between several servers, then you HAVE to adopt sql server based session management anyway (memory between the servers can't and is not shared anyway).
So, while memory based session can and does work quite well, I simple gave up on that choice. Turn on and adopt SQL server session based management, and session will become rock solid.
Of course the only real big downside?
The whole system can and will take a performance hit - maybe 10%. So, it really depends on how high of a user load your web server system has now. In the vast majority of cases, I never noticed much difference.
Do note that some testing should be done, since with SQL server based session management, then objects are serialized before saving into sql server (this is all automatic - no code changes required).
However, in some case, I have found some objects would all of a sudden not work. A good example I recall was placing a data row into session. Data rows can't be serialized (why I have no idea!!!). So, some code can be effected by this choice, but it rather rare in my experience. (that one lone case - I just changed to using a datatable with one row as opposed to using session() and shoving in a data row object).
Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada