473,508 Members | 2,457 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Server.Transfer and Load Balanced Environments

Greetings!

I would like to use Server.Transfer to redirect users to a given page,
while maintaining the state of form fields. This works fine on a single
server.

However, this will be deployed in a load balanced environment. I know
that Session variables and load balanced environments don't mix. Do I
have a cause for concern with Server.Transfer as well?

Thanks in advance.
Chris
Sep 8 '06 #1
13 2971

"Chris Bellini" <ch*************@spam.chrisbellini.blows.comwrot e in
message news:eH**************@TK2MSFTNGP03.phx.gbl...
Greetings!

I would like to use Server.Transfer to redirect users to a given page,
while maintaining the state of form fields. This works fine on a single
server.

However, this will be deployed in a load balanced environment. I know
that Session variables and load balanced environments don't mix. Do I
have a cause for concern with Server.Transfer as well?

Thanks in advance.
Chris
Server transfer will not transfer the request to another server even in a
load balanced system.
Sep 8 '06 #2
I haven't done extensive testing of this, but I am fairly certain that both
server.transfer and server.execute will stay on the same server. At least
that's the theory ... I'll repeat that I haven't done any thorough testing
of this. As with most things, if you have concerns it shouldn't take much
to set up a test.

A


"Chris Bellini" <ch*************@spam.chrisbellini.blows.comwrot e in
message news:eH**************@TK2MSFTNGP03.phx.gbl...
Greetings!

I would like to use Server.Transfer to redirect users to a given page,
while maintaining the state of form fields. This works fine on a single
server.

However, this will be deployed in a load balanced environment. I know
that Session variables and load balanced environments don't mix. Do I
have a cause for concern with Server.Transfer as well?

Thanks in advance.
Chris

Sep 8 '06 #3
Aaron Bertrand [SQL Server MVP] wrote:
I haven't done extensive testing of this, but I am fairly
certain that both server.transfer and server.execute will
stay on the same server. At least that's the theory ...
They HAVE TO stay on the same server. They share a response stream (unlike
Response.Redirect, which tells the browser to send a new request, and
subsequently does not share a response stream with the original request).

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.
Sep 8 '06 #4
They HAVE TO stay on the same server. They share a response stream (unlike
Response.Redirect, which tells the browser to send a new request, and
subsequently does not share a response stream with the original request).
Right, after I posted I thought about it a bit more, and of course
server.transfer/execute would not possibly be able to send anything back out
to the load balancer, because by definition they stay local.
Sep 8 '06 #5
Aaron Bertrand [SQL Server MVP] wrote:
>They HAVE TO stay on the same server. They share a response stream (unlike
Response.Redirect, which tells the browser to send a new request, and
subsequently does not share a response stream with the original request).

Right, after I posted I thought about it a bit more, and of course
server.transfer/execute would not possibly be able to send anything back out
to the load balancer, because by definition they stay local.

So it's safe to say that shouldn't run into any issues of having
hidden form fields disappear on me after a call to Server.Transfer?
Chris
Sep 9 '06 #6
Chris Bellini wrote:
So it's safe to say that shouldn't run into any issues of
having hidden form fields disappear on me after a call to
Server.Transfer?
Hidden form fields are a client-side issue. The server only knows requests.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.
Sep 9 '06 #7

"Chris Bellini" <ch*************@spam.chrisbellini.blows.comwrot e in
message news:u3**************@TK2MSFTNGP03.phx.gbl...
Aaron Bertrand [SQL Server MVP] wrote:
They HAVE TO stay on the same server. They share a response stream
(unlike
Response.Redirect, which tells the browser to send a new request, and
subsequently does not share a response stream with the original
request).

Right, after I posted I thought about it a bit more, and of course
server.transfer/execute would not possibly be able to send anything back
out
to the load balancer, because by definition they stay local.
So it's safe to say that shouldn't run into any issues of having
hidden form fields disappear on me after a call to Server.Transfer?
No you shouldn't. All form fields will appear to the transfered to page the
same as they would have to the original target.
>
Chris

Sep 10 '06 #8
Anthony Jones wrote:
No you shouldn't. All form fields will appear to the transfered to page the
same as they would have to the original target.
>Chris

Phew, that's good to hear :) Thanks.
Chris
Sep 10 '06 #9
Anthony Jones wrote:
>So it's safe to say that shouldn't run into any issues of
having hidden form fields disappear on me after a call to
Server.Transfer?

No you shouldn't. All form fields will appear to the
transfered to page the same as they would have to the
original target.
That's not technically correct. The two scripts share Request and Response
objects, which are server-side, while form fields (hidden or otherwise) are
client-side constructs.

The conclusion is correct, however. There should be no loss of Request
elements in the transfer from one script to another.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.
Sep 11 '06 #10

"Dave Anderson" <NY**********@spammotel.comwrote in message
news:uI**************@TK2MSFTNGP04.phx.gbl...
Anthony Jones wrote:
So it's safe to say that shouldn't run into any issues of
having hidden form fields disappear on me after a call to
Server.Transfer?
No you shouldn't. All form fields will appear to the
transfered to page the same as they would have to the
original target.

That's not technically correct. The two scripts share Request and Response
objects, which are server-side, while form fields (hidden or otherwise)
are
client-side constructs.
What is Request.Form("MyHiddenField") ??
ASP is aware of Form fields, it is not, from an ASP point of view, purely a
'client side construct' even though it is from a HTTP point of view. Do we
have to keep doing this Dave??
The conclusion is correct, however. There should be no loss of Request
elements in the transfer from one script to another.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message.
Use
of this email address implies consent to these terms.


Sep 11 '06 #11
Anthony Jones wrote:
>That's not technically correct. The two scripts share Request and
Response objects, which are server-side, while form fields (hidden
or otherwise) are client-side constructs.

What is Request.Form("MyHiddenField") ??
It is an element of the [Form] collection of a Request. There is no
requirement that it be associated with a field, which I can easily
demonstrate with an XMLHttpRequest object. Or the Gecko extension
LiveHTTPHeaders, for that matter.
ASP is aware of Form fields, it is not, from an ASP point of view,
purely a 'client side construct' even though it is from a HTTP
point of view.
I wholeheartedly disagree. The only thing ASP knows about the client is what
the client tells it -- the content of the Request.
Do we have to keep doing this Dave??
No.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.
Sep 11 '06 #12

"Dave Anderson" <NY**********@spammotel.comwrote in message
news:ez**************@TK2MSFTNGP04.phx.gbl...
Anthony Jones wrote:
That's not technically correct. The two scripts share Request and
Response objects, which are server-side, while form fields (hidden
or otherwise) are client-side constructs.
What is Request.Form("MyHiddenField") ??

It is an element of the [Form] collection of a Request.
If you were to give that a single word label what would it be?

No let me guess anything that but 'Field' right?

>There is no
requirement that it be associated with a field, which I can easily
demonstrate with an XMLHttpRequest object. Or the Gecko extension
LiveHTTPHeaders, for that matter.
Some might call that emulation ;)
>
ASP is aware of Form fields, it is not, from an ASP point of view,
purely a 'client side construct' even though it is from a HTTP
point of view.

I wholeheartedly disagree. The only thing ASP knows about the client is
what
the client tells it -- the content of the Request.
ASP doesn't care about the client but it does support the 'concept' of a
Form which has fields. How the client may or may not represent it isn't
it's business but to say tha ASP doesn't have 'Form field constructs' is odd
to say the least when it clearly exposes a collection of values (which I
would call fields) in property called Form is bit like saying black is
white.
>
Do we have to keep doing this Dave??

No.
Yet we end up doing it anyway. Daft but fun.
>

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message.
Use
of this email address implies consent to these terms.


Sep 11 '06 #13
Anthony Jones wrote:
>It is an element of the [Form] collection of a Request.

If you were to give that a single word label what would it be?
I already gave one: element. The only other one I would consider is item**,
but that has special meaning in this case, since the element is an object
with properties .Count, and .Item (Item is the default property).
No let me guess anything that but 'Field' right?
Wrong. See above.
>There is no requirement that it be associated with a field,
which I can easily demonstrate with an XMLHttpRequest object.
Or the Gecko extension LiveHTTPHeaders, for that matter.

Some might call that emulation ;)
I call it constructing a request, which is nothing more than a message.
ASP doesn't care about the client but it does support the
'concept' of a Form which has fields.
I would agree that HTML supports that concept, but not ASP.
How the client may or may not represent it isn't it's business...
The client renders the HTML and creates Requests. So if there is a question
of how the client represents something, that should center on the Response
(which creates the HTML), and not on the Request.

You have it exactly backward. The client creates the request, parts of which
ASP assembles into a Request Object and its Form Collection for exposure to
the script. The ASP script creates a Response message, which usually
contains a status of 200, a content-type of text/html, and a text string
representing an HTML document, among other things. The browser chooses how
to represent that HTML document fragment of the response. There is no
"concept of a form" in that response outside the HTML.
but to say tha ASP doesn't have 'Form field constructs' is odd to
say the least when it clearly exposes a collection of values
(which I would call fields) in property called Form is bit like
saying black is white.
It only looks like a "collection of values" to a VBScripter. Those of us who
write ASP in JScript know the truth: Request.Form is a collection of
objects. Admittedly, that fact alone does not make it any more or any less
like a collection of *fields*. But neither does the fact that ASP names the
collection "Form".

Consider this JScript illustration of your argument:

var black = {Count:1,Item:"black"}
if (black == "black") {
Response.Write(black + " is black")
} else {
Response.Write(black + " is white")
}

The output? [object Object] is white.


** I would use item because the JScript Enumerator object exposes them via
..item().
--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms.
Sep 11 '06 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
1484
by: Mohit | last post by:
Hello Friends, Our department has created a few (6) Web Applications and all these applications share a common piece of code which does the "User Authentication". I would like to isolate the...
7
3544
by: Lyn Duong | last post by:
Hi all I'm trying to transfer data from sqlserver 2000 to ibm db2 AIX 8.1.4 using dts packages This works when I use db2 ole db drivers but the problem is that the transfer is very slow as the...
4
2087
by: Harsh Thakur | last post by:
Hi, I'd like to know the performance related differences between Response.Redirect and Server.Transfer. I'd like to redirect the user to a different page. I can either do a...
2
3194
by: Mr Wizard | last post by:
I am going through the front controller http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/ImpFrontControllerInASP.asp and all works well except when the server.transfer...
1
1180
by: Shikari Shambu | last post by:
Hi, I have a ASP.NEt web application with forms authentication deployed on single server. I do not use Session State, just the HttpContext and so on. Now, we want to move to a load balanced...
6
3234
by: Stephen | last post by:
Hi All! This really is a file permissions problem ... although I'm not sure how to solve it. Any assistance would be greatly appreciated. I have a series of load balanced servers. Each of...
5
3756
by: Steven Nagy | last post by:
Hi all, What are the major considerations when considering Server.Transfer? I have some legacy apps (when I say legacy, I mean ASP.NET1.0) that use Server.Transfer for almost everything. I...
2
3089
by: =?Utf-8?B?YWxiZXJ0b3Nvcmlh?= | last post by:
Hi, I'm using Threads, and when I try to do Server.Transfer, I recieved an error. (child object does not exist...) My Code: Dim t As New Thread(AddressOf Hilo) Private Sub Hilo()...
6
3394
by: BA | last post by:
Hi Everyone, I have an application that sits behind a server farm, the application needs to pass its NLB IP address in the message that it sends to another service. From C# code, how can I...
0
7224
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
7323
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
7379
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
1
7038
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
7493
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
5625
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
4706
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
1
763
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
415
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.