Recent content by runprn

Thanks, TR. It is a rather convoluted mess, with some session data static, and other data dynamic (depending on verious user-based actions). All told, there are between 10-20 session objects per session. Many are not instantiated until certain tasks are performed, and some are immediately...

I appreciate where you're coming from, but don't necessarily agree. In the Java model, for example, enterprise Java beans and/or other class objects are used exactly for this purpose: Encapsulating data so that return trips to the database can be avoided. There are pros and cons on either side...

I manage a pretty massive intranet system that currently uses session state to hold the majority of a user's permissions, group access lists, preferences, etc. In the beginning, that approach worked fine, but now, we are reaching the point where the tax on server memory is affecting performance...