By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,569 Members | 1,394 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,569 IT Pros & Developers. It's quick & easy.

Server.Execute() and Application.Lock

P: n/a
Hi All

I am using Application.lock to protect a reference to a COM+ object while
calling Server.Execute() to another ASP page. I am doing this to pass the
object's reference to the other page, and I CAN'T rely on the session
object.

Is this a safe way to protect the object reference? i.e. does the
Application object remain locked when calling Server.Execute() ?

Help/advice will be greatly appreciated.

Thanks ahead

Elie Grouchko

**********************************

The code looks like that:

page1.asp
---------------------
dim ObjectRef
set ObjectRef = Server.CreateObject("Server.Object")
....
Application.Lock
set Application("reference") = ObjectRef
Server.Execute("page2.asp")
page2.asp
---------------------
dim ObjectRef
set ObjectRef=Application("reference")
set Application("reference") = nothing
Application.Unlock
Jul 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Elie,

The server.execute actually executes the page as if it were a part of the
page where it is executed. Kinda like "include." Therefore, the application
is locked for the application variables against any modification. If I were
you, I would just do the application lock and unlock on the same page, in
your case on the second one. The Application variables can be accessed but
only for readonly access.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Elie Grouchko" <eg*******@hotmail.com> wrote in message
news:uY**************@TK2MSFTNGP11.phx.gbl...
Hi All

I am using Application.lock to protect a reference to a COM+ object while
calling Server.Execute() to another ASP page. I am doing this to pass the
object's reference to the other page, and I CAN'T rely on the session
object.

Is this a safe way to protect the object reference? i.e. does the
Application object remain locked when calling Server.Execute() ?

Help/advice will be greatly appreciated.

Thanks ahead

Elie Grouchko

**********************************

The code looks like that:

page1.asp
---------------------
dim ObjectRef
set ObjectRef = Server.CreateObject("Server.Object")
...
Application.Lock
set Application("reference") = ObjectRef
Server.Execute("page2.asp")
page2.asp
---------------------
dim ObjectRef
set ObjectRef=Application("reference")
set Application("reference") = nothing
Application.Unlock

Jul 19 '05 #2

P: n/a
Elie,

The server.execute actually executes the page as if it were a part of the
page where it is executed. Kinda like "include." Therefore, the application
is locked for the application variables against any modification. If I were
you, I would just do the application lock and unlock on the same page, in
your case on the second one. The Application variables can be accessed but
only for readonly access.

--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Elie Grouchko" <eg*******@hotmail.com> wrote in message
news:uY**************@TK2MSFTNGP11.phx.gbl...
Hi All

I am using Application.lock to protect a reference to a COM+ object while
calling Server.Execute() to another ASP page. I am doing this to pass the
object's reference to the other page, and I CAN'T rely on the session
object.

Is this a safe way to protect the object reference? i.e. does the
Application object remain locked when calling Server.Execute() ?

Help/advice will be greatly appreciated.

Thanks ahead

Elie Grouchko

**********************************

The code looks like that:

page1.asp
---------------------
dim ObjectRef
set ObjectRef = Server.CreateObject("Server.Object")
...
Application.Lock
set Application("reference") = ObjectRef
Server.Execute("page2.asp")
page2.asp
---------------------
dim ObjectRef
set ObjectRef=Application("reference")
set Application("reference") = nothing
Application.Unlock

Jul 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.