On Nov 30, 2005, at 12:30 AM, Perrin Harkins wrote:
It certainly can be a scoping issue, but it could also be a locking
issue. Without seeing a test case that causes it, it's pretty hard to
guess.
I'd suggest running data dumper and storing each iteration of a
'session' variable to a different text file -- then looking at them
and seeing how/why they're growing large.
At my last fulltime job, i had to fix a .NET project another agency
made. the devry graduate who programmed it saved a serialized
(encrypted) version of the session user as a hidden formfield to get
past browser cookies and an inability to munge server URIs. aside
from the user account info being obscenely big (40k ?! on first load)
-- he also had it save recursively.
ie:
session{user}
session{user{user}}
session{user{user}{user}}
so after 4 pageloads, you had a 200k html page because of that
serialized session. Not good , nor necessary.
Once, on something I quickly threw together, I stored the last
requested URL in the session var. a typo ended up in me essentially
appending the URL as a history, not replacing it entirely. a couple
hours of testing, and I had a 300k session variable and i couldn't
figure out why performance was degrading.
