| Author |
 Topic  |
|
|
Id
Junior Member
USA
129 Posts |
 Posted - 30 June 2001 : 11:56:30
|
I'm in the process of setting up some security features on an ASP page I'm building, and i've got all my security settings stored in a database, is it possible to store a database recordset in a session variable? and if so, what would be the best way of going about doing it?
|
|
|
Doug G
Support Moderator
USA
6493 Posts |
Posted - 30 June 2001 : 21:16:37
|
Yes, you can use code like
Set Session("myRS") = myRS
There are performance and scalability issues you need to understand if you're using session objects. There is a lot of info on the web, much of which will say it's a "bad thing" to use Session state.
======
Doug G
====== |
 |
|
|
Id
Junior Member
USA
129 Posts |
Posted - 30 June 2001 : 21:44:52
|
<<Disregard>>
Edited by - Id on 30 June 2001 21:48:23 |
|
|
|
aspdesigner
Junior Member
165 Posts |
Posted - 30 June 2001 : 21:45:19
|
It is NOT a good idea to store a recordset in a session variable! Doing so can cause severe performance problems on your server, due to the default threading model settings for ADO objects. It is possible to change the theading model, but this requires that you be able to customize Windows on that machine (unlikely unless you are hosting in-house), and the result makes ADO incompatible with Microsoft Access! (even worse!)
It is also not a good idea to store ADO connection objects in a session variable.
If you do need to be able to access certain security-related settings from session, why not just read them from the database once (like when users login), and then save only those settings you need in session as simple variables instead?
|
|
|
|
Id
Junior Member
USA
129 Posts |
Posted - 30 June 2001 : 21:48:02
|
I never thought of it like that, that's a good idea, i'm surprised something that simple slipped past me, thanks for the suggestion
|
|
|
|
aspdesigner
Junior Member
165 Posts |
Posted - 30 June 2001 : 22:24:20
|
You're welcome, glad I could help. Experience can be the best teacher sometimes - I used that same approach for a security system I wrote a while back! 
|
|
|
|
Doug G
Support Moderator
USA
6493 Posts |
Posted - 01 July 2001 : 13:12:43
|
quote:
It is NOT a good idea to store a recordset in a session variable!
Sometimes it is a good idea. It really depends on the circumstances, as is the case with most programming issues. There is no way you can make a hard & fast rule that applies to every situation you will encounter.
======
Doug G
====== |
|
|
|
aspdesigner
Junior Member
165 Posts |
Posted - 02 July 2001 : 01:25:59
|
I disagree. I did not "make up" this advise, it came from Microsoft. For the more technically inclined, following are some exerpts from them -
quote:
"While caching data in the Application or Session object can be a good idea, caching
COM objects can have serious pitfalls. It is often tempting to stuff frequently-used COM
objects into the Application or Session objects. Unfortunately, many COM objects,
including all of those written in Visual Basic 6.0 or earlier, can cause serious
bottlenecks when stored in the Application or Session objects.
Specifically, any component that is not agile will cause performance bottlenecks when cached in the Session or Application objects."
"Apartment-threaded components and other non-agile components work best at page
scope (that is, they are created and destroyed on a single ASP page)."
"What goes wrong if you cache non-agile components? A non-agile component cached
in the Session object will "lock down" the Session to an ASP worker thread. ASP maintains a pool of worker threads that services requests. Normally, a new request is handled by the first-available worker thread. If a Session is locked down to a thread, then the request has to wait for its associated thread to become available."
"Storing non-agile components at Application scope has an even worse effect on
performance. ASP has to create a special thread to run non-agile, Application-scoped
components. This has two consequences: all calls have to be marshaled to this thread
and all calls are serialized. Marshaling means that the parameters have to be stored in a shared area of memory; an expensive context switch is made to the special thread;
the component's method is executed; the results are marshaled into a shared area;
and another expensive context switch reverts control to the original thread. Serialization means that all methods are run one at a time. It is not possible for two different ASP worker threads to be executing methods on the shared component simultaneously. This kills concurrency, especially on multiprocessor machines. Worse still, all non-agile Application-scoped components share one thread (the "Host STA"),
so the effects of serialization are even more marked."
In the default threading model configuration, ADO components are not agile, and so storing them in Session or Application variables result in the problems as outlined above.
As I explained in my original post, there is a way to change ADO's threading model, however, this causes its own problems - it requires that you have the ability to modify your server's Windows configuration (unlikely unless you are hosting in-house); and it results in making ADO incompatible with Microsoft Access!
Edited by - aspdesigner on 02 July 2001 01:46:10 |
|
|
| |
Topic |
|
Topic Locked
