Re: Storing objects in Session Variables - exactly why not?
From: Bob Barrows [MVP] (reb01501_at_NOyahoo.SPAMcom)
Date: 03/27/05
- Next message: Thomas: "Re: Storing objects in Session Variables - exactly why not?"
- Previous message: Steven Burn: "Re: localhost..."
- In reply to: Thomas: "Re: Storing objects in Session Variables - exactly why not?"
- Next in thread: Thomas: "Re: Storing objects in Session Variables - exactly why not?"
- Reply: Thomas: "Re: Storing objects in Session Variables - exactly why not?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 27 Mar 2005 11:04:17 -0500
Thomas wrote:
>> Thanks for the code. I will try it myself sometime.
>> Can you share the results of your tests? How much of a difference was
>> achieved by using the Session-bound object?
>
> it was roughly in the regions of 20% performance gain. i will
> defenitely redo my tests in the near future. the configuration has
> changed (iis6, windows2003, new server, new ado). also from what i
> read here and in your links, my solution might not be faster anymore
> in the current environement. if i can get rid of manual pooling
> without performance-loss, i'll do this happily - especially as this
> would free up ressources.
>> PS. Have you at least changed the threading model of your ADO
>> objects by using the makfre15.bat batch file which can be found in
>> your ADO folder? If you are not using Jet, you really should do
>> this. Most of my objections to caching the object in session go away
>> if you change the treading model.
>>>
>
> nope. i don't even have this batch file... maybe because in
> windows2003 mdac 2.8 is already included?
Interesting. I do not see it on one of our W2003 servers either. Several
possibilities come to mind:
1. It's no longer necessary to do this change in W2003
2. They don't want you doing this change in W2003
3. You can't make this change in W2003
I'm not sure which is the correct reason.
All the batch file does is run the registry merge file called ADOFRE15.REG
(contained in the same folder) that contains these registry keys:
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000507-0000-0010-8000-00AA006D2EA4}\InprocServer32]
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000514-0000-0010-8000-00AA006D2EA4}\InprocServer32]
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0000050B-0000-0010-8000-00AA006D2EA4}\InprocServer32]
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32]
"ThreadingModel"="Both"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000541-0000-0010-8000-00AA006D2EA4}\InprocServer32]
"ThreadingModel"="Both"
I don't have access to the registries on our W2003 servers right now so I
can't investigate more thoroughly.
>
>> Would it be too much to ask for you to repeat your tests using
>> CreateObject instead of Server.CreateObject?
>
> not at all. i'll prepare some new tests. i always thought it
> Server.CreateObject was recommended over CreateObject
As did I. I recently had it pointed out to me that things had changed.
Bob Barrows
-- Microsoft MVP - ASP/ASP.NET Please reply to the newsgroup. This email account is my spam trap so I don't check it very often. If you must reply off-line, then remove the "NO SPAM"
- Next message: Thomas: "Re: Storing objects in Session Variables - exactly why not?"
- Previous message: Steven Burn: "Re: localhost..."
- In reply to: Thomas: "Re: Storing objects in Session Variables - exactly why not?"
- Next in thread: Thomas: "Re: Storing objects in Session Variables - exactly why not?"
- Reply: Thomas: "Re: Storing objects in Session Variables - exactly why not?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|