Mixing
Why does my ASP.NET MVC application fire Session_Start multiple times for a single session?
We have an MVC.NET application that encounters fatal errors when it restarts. In our Session_Start event handler, we add the session id to a dictionary. In the Session_End handler, we remove it. Consider the following sequence of requests:
GET home.mvc
<application restarts>
GET main.css
GET banner.jpg
GET somedata.mvc
...
Because of the way the application is architected, this sort of sequence happens fairly frequently if you do a rebuild while the application is open in a browser window. That wouldn't be terribly concerning except that I see it in production environments too. For example, it will occur (albeit rarely) when you edit web.config.
The requests following the restart are all due to links in the home page or AJAX calls from JavaScript.
What I observe is that .NET handles the first 5 requests in parallel. Each such request causes it to fire the Session_Start event. After a short time, it fires the Session_End event 3 times. To be clear, each Session_Start corresponds to the exact same session. They all have the same session id and the IsNewSession property is true for all session state objects. Also, the Session_End events do not correspond to the session being killed. The session persists, along with any data stored in session state.
I need to either prevent it from firing Session_Start more than once or figure out how to tell when Session_End doesn't really mean that the session has ended.
asp.net asp.net-mvc
asked Jul 29 '10 at 18:46
Peter Ruderman
10.1k2352
add a comment |
We have an MVC.NET application that encounters fatal errors when it restarts. In our Session_Start event handler, we add the session id to a dictionary. In the Session_End handler, we remove it. Consider the following sequence of requests:
GET home.mvc
<application restarts>
GET main.css
GET banner.jpg
GET somedata.mvc
...
Because of the way the application is architected, this sort of sequence happens fairly frequently if you do a rebuild while the application is open in a browser window. That wouldn't be terribly concerning except that I see it in production environments too. For example, it will occur (albeit rarely) when you edit web.config.
The requests following the restart are all due to links in the home page or AJAX calls from JavaScript.
What I observe is that .NET handles the first 5 requests in parallel. Each such request causes it to fire the Session_Start event. After a short time, it fires the Session_End event 3 times. To be clear, each Session_Start corresponds to the exact same session. They all have the same session id and the IsNewSession property is true for all session state objects. Also, the Session_End events do not correspond to the session being killed. The session persists, along with any data stored in session state.
I need to either prevent it from firing Session_Start more than once or figure out how to tell when Session_End doesn't really mean that the session has ended.
asp.net asp.net-mvc
asked Jul 29 '10 at 18:46
Peter Ruderman
10.1k2352
What is it that you need to deal with? Are you saying there is a discrepancy between your dictionary and asp.net's internal dictionary? At what point are you finding the discrepancy?
– matt-dot-net
Jul 30 '10 at 17:41
Is the dictionary stored in an application variable or in a session variable?
– Joel Etherton
Jul 30 '10 at 19:38
The dictionary is an application variable.
– Peter Ruderman
Jul 30 '10 at 20:24
don't you useSession_StartandSession_Endfor Count users ? WebFarm. Any source code samplefull?
– PreguntonCojoneroCabrón
Nov 5 '16 at 12:55
I don't remember exactly what this was all about (it was 6 years ago), but the application was a web interface for a legacy system. There was no way around storing state and a web farm was not a scenario we had to consider. In the end, it turned out that IIS/MVC was a bad fit for us and we ended up reworking the application as a WCF REST service.
– Peter Ruderman
Nov 7 '16 at 17:16
add a comment |
We have an MVC.NET application that encounters fatal errors when it restarts. In our Session_Start event handler, we add the session id to a dictionary. In the Session_End handler, we remove it. Consider the following sequence of requests:
GET home.mvc
<application restarts>
GET main.css
GET banner.jpg
GET somedata.mvc
...
Because of the way the application is architected, this sort of sequence happens fairly frequently if you do a rebuild while the application is open in a browser window. That wouldn't be terribly concerning except that I see it in production environments too. For example, it will occur (albeit rarely) when you edit web.config.
The requests following the restart are all due to links in the home page or AJAX calls from JavaScript.
What I observe is that .NET handles the first 5 requests in parallel. Each such request causes it to fire the Session_Start event. After a short time, it fires the Session_End event 3 times. To be clear, each Session_Start corresponds to the exact same session. They all have the same session id and the IsNewSession property is true for all session state objects. Also, the Session_End events do not correspond to the session being killed. The session persists, along with any data stored in session state.
I need to either prevent it from firing Session_Start more than once or figure out how to tell when Session_End doesn't really mean that the session has ended.
asp.net asp.net-mvc
asked Jul 29 '10 at 18:46
Peter Ruderman
10.1k2352
We have an MVC.NET application that encounters fatal errors when it restarts. In our Session_Start event handler, we add the session id to a dictionary. In the Session_End handler, we remove it. Consider the following sequence of requests:
GET home.mvc
<application restarts>
GET main.css
GET banner.jpg
GET somedata.mvc
...
Because of the way the application is architected, this sort of sequence happens fairly frequently if you do a rebuild while the application is open in a browser window. That wouldn't be terribly concerning except that I see it in production environments too. For example, it will occur (albeit rarely) when you edit web.config.
The requests following the restart are all due to links in the home page or AJAX calls from JavaScript.
What I observe is that .NET handles the first 5 requests in parallel. Each such request causes it to fire the Session_Start event. After a short time, it fires the Session_End event 3 times. To be clear, each Session_Start corresponds to the exact same session. They all have the same session id and the IsNewSession property is true for all session state objects. Also, the Session_End events do not correspond to the session being killed. The session persists, along with any data stored in session state.
I need to either prevent it from firing Session_Start more than once or figure out how to tell when Session_End doesn't really mean that the session has ended.
asp.net asp.net-mvc
asp.net asp.net-mvc
asked Jul 29 '10 at 18:46
Peter Ruderman
10.1k2352
asked Jul 29 '10 at 18:46
Peter Ruderman
10.1k2352
edited Nov 19 '18 at 17:14
asked Jul 29 '10 at 18:46
Peter Ruderman
10.1k2352
asked Jul 29 '10 at 18:46
Peter Ruderman
10.1k2352
asked Jul 29 '10 at 18:46
Peter Ruderman
10.1k2352
10.1k2352
What is it that you need to deal with? Are you saying there is a discrepancy between your dictionary and asp.net's internal dictionary? At what point are you finding the discrepancy?
– matt-dot-net
Jul 30 '10 at 17:41
Is the dictionary stored in an application variable or in a session variable?
– Joel Etherton
Jul 30 '10 at 19:38
The dictionary is an application variable.
– Peter Ruderman
Jul 30 '10 at 20:24
don't you useSession_StartandSession_Endfor Count users ? WebFarm. Any source code samplefull?
– PreguntonCojoneroCabrón
Nov 5 '16 at 12:55
I don't remember exactly what this was all about (it was 6 years ago), but the application was a web interface for a legacy system. There was no way around storing state and a web farm was not a scenario we had to consider. In the end, it turned out that IIS/MVC was a bad fit for us and we ended up reworking the application as a WCF REST service.
– Peter Ruderman
Nov 7 '16 at 17:16
add a comment |
What is it that you need to deal with? Are you saying there is a discrepancy between your dictionary and asp.net's internal dictionary? At what point are you finding the discrepancy?
– matt-dot-net
Jul 30 '10 at 17:41
Is the dictionary stored in an application variable or in a session variable?
– Joel Etherton
Jul 30 '10 at 19:38
The dictionary is an application variable.
– Peter Ruderman
Jul 30 '10 at 20:24
don't you useSession_StartandSession_Endfor Count users ? WebFarm. Any source code samplefull?
– PreguntonCojoneroCabrón
Nov 5 '16 at 12:55
I don't remember exactly what this was all about (it was 6 years ago), but the application was a web interface for a legacy system. There was no way around storing state and a web farm was not a scenario we had to consider. In the end, it turned out that IIS/MVC was a bad fit for us and we ended up reworking the application as a WCF REST service.
– Peter Ruderman
Nov 7 '16 at 17:16
What is it that you need to deal with? Are you saying there is a discrepancy between your dictionary and asp.net's internal dictionary? At what point are you finding the discrepancy?
– matt-dot-net
Jul 30 '10 at 17:41
What is it that you need to deal with? Are you saying there is a discrepancy between your dictionary and asp.net's internal dictionary? At what point are you finding the discrepancy?
– matt-dot-net
Jul 30 '10 at 17:41
Is the dictionary stored in an application variable or in a session variable?
– Joel Etherton
Jul 30 '10 at 19:38
Is the dictionary stored in an application variable or in a session variable?
– Joel Etherton
Jul 30 '10 at 19:38
The dictionary is an application variable.
– Peter Ruderman
Jul 30 '10 at 20:24
The dictionary is an application variable.
– Peter Ruderman
Jul 30 '10 at 20:24
don't you use
Session_Start and Session_End for Count users ? WebFarm. Any source code samplefull?– PreguntonCojoneroCabrón
Nov 5 '16 at 12:55
don't you use
Session_Start and Session_End for Count users ? WebFarm. Any source code samplefull?– PreguntonCojoneroCabrón
Nov 5 '16 at 12:55
I don't remember exactly what this was all about (it was 6 years ago), but the application was a web interface for a legacy system. There was no way around storing state and a web farm was not a scenario we had to consider. In the end, it turned out that IIS/MVC was a bad fit for us and we ended up reworking the application as a WCF REST service.
– Peter Ruderman
Nov 7 '16 at 17:16
I don't remember exactly what this was all about (it was 6 years ago), but the application was a web interface for a legacy system. There was no way around storing state and a web farm was not a scenario we had to consider. In the end, it turned out that IIS/MVC was a bad fit for us and we ended up reworking the application as a WCF REST service.
– Peter Ruderman
Nov 7 '16 at 17:16
add a comment |
3 Answers
3
active
oldest
votes
The answer to this question turned out to be fairly straight-foward, though the behaviour was certainly confusing.
Normally, MVC will synchronize all requests to an application on the application's session state lock (because MVC's http module is marked as requiring session state). In my scenario, the application restarts after serving the main page. Thus, when the main page-related requests come in, there is no session state for that session id yet and the requests execute in parallel.
I see 5 parallel requests because I'm developing on XP and desktop versions of IIS are limited to 5 concurrent requests. Since the session state object does not exist for any of these requests, each request creates a new session state object and fires Session_Start. Four of the requests go to MVC action methods. Since these require session state, .NET tries to synchronize the created session state objects with the backing store once the requests complete.
Only the first synchronization can succeed. .NET simply discards the three extra session state objects and fires Session_End for each one. .NET does not attempt to synchronize the fifth session state object with the backing store because it was created for an asynchronous http module which is marked as requiring readonly session state.
So, the fix has two parts:
(1) In my Session_Start handler, I now check if the session state object is readonly. If it is, then I return immediately without doing anything. .NET will not fire a corresponding Session_End, and thus anything I do won't be cleaned up properly anyway.
(2) I now keep a reference count in my dictionary. I increment the count everytime a Session_Start handler tries to add a session id and decrement it everytime Session_End tries to remove one. Once the count reaches 0, I remove the session id from my dictionary.
answered Aug 3 '10 at 15:57
Peter Ruderman
10.1k2352
its a bit old.. but I'm not following why the 5 requests are in parallel. Is this spawned from a single request? Why are 5 created at the same time?
– Adam Tuliper - MSFT
Jun 7 '11 at 14:08
Multiple requests are created at the same time because the browser sends multiple requests without waiting for them to return. (After receiving the web page, the browser immediately requests all referenced images, style sheets, and so on.) The number 5 comes up because the machine was a Windows XP box. IIS limits applications to processing 5 simultaneous requests on desktop machines. On a server box, the number would have been higher.
– Peter Ruderman
Jun 9 '11 at 15:15
add a comment |
The session id can be reused if the client sends you a value that has expired. Read about the <sessionState> element's regenerateExpiredSessionId attribute here and notice that the default value is "true"
You might also find this interesting:
answered Jul 30 '10 at 13:05
matt-dot-net
3,8711623
Thanks for your reply Matt, but I believe I've been barking up the wrong tree. I'll update my question with some additional information I discovered yesterday.
– Peter Ruderman
Jul 30 '10 at 13:51
add a comment |
I had this happen to me for an old ASP.NET app in development - turned out that RequireSSL was set to True for cookies... which of course meant that the session cookie wasn't kept/re-issued by the client (localhost, non SSL) - so subsequent requests created new session(s).
answered Dec 22 '15 at 11:41
Nathan
5,02322554
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f3365942%2fwhy-does-my-asp-net-mvc-application-fire-session-start-multiple-times-for-a-sing%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The answer to this question turned out to be fairly straight-foward, though the behaviour was certainly confusing.
Normally, MVC will synchronize all requests to an application on the application's session state lock (because MVC's http module is marked as requiring session state). In my scenario, the application restarts after serving the main page. Thus, when the main page-related requests come in, there is no session state for that session id yet and the requests execute in parallel.
I see 5 parallel requests because I'm developing on XP and desktop versions of IIS are limited to 5 concurrent requests. Since the session state object does not exist for any of these requests, each request creates a new session state object and fires Session_Start. Four of the requests go to MVC action methods. Since these require session state, .NET tries to synchronize the created session state objects with the backing store once the requests complete.
Only the first synchronization can succeed. .NET simply discards the three extra session state objects and fires Session_End for each one. .NET does not attempt to synchronize the fifth session state object with the backing store because it was created for an asynchronous http module which is marked as requiring readonly session state.
So, the fix has two parts:
(1) In my Session_Start handler, I now check if the session state object is readonly. If it is, then I return immediately without doing anything. .NET will not fire a corresponding Session_End, and thus anything I do won't be cleaned up properly anyway.
(2) I now keep a reference count in my dictionary. I increment the count everytime a Session_Start handler tries to add a session id and decrement it everytime Session_End tries to remove one. Once the count reaches 0, I remove the session id from my dictionary.
answered Aug 3 '10 at 15:57
Peter Ruderman
10.1k2352
its a bit old.. but I'm not following why the 5 requests are in parallel. Is this spawned from a single request? Why are 5 created at the same time?
– Adam Tuliper - MSFT
Jun 7 '11 at 14:08
Multiple requests are created at the same time because the browser sends multiple requests without waiting for them to return. (After receiving the web page, the browser immediately requests all referenced images, style sheets, and so on.) The number 5 comes up because the machine was a Windows XP box. IIS limits applications to processing 5 simultaneous requests on desktop machines. On a server box, the number would have been higher.
– Peter Ruderman
Jun 9 '11 at 15:15
add a comment |
The answer to this question turned out to be fairly straight-foward, though the behaviour was certainly confusing.
Normally, MVC will synchronize all requests to an application on the application's session state lock (because MVC's http module is marked as requiring session state). In my scenario, the application restarts after serving the main page. Thus, when the main page-related requests come in, there is no session state for that session id yet and the requests execute in parallel.
I see 5 parallel requests because I'm developing on XP and desktop versions of IIS are limited to 5 concurrent requests. Since the session state object does not exist for any of these requests, each request creates a new session state object and fires Session_Start. Four of the requests go to MVC action methods. Since these require session state, .NET tries to synchronize the created session state objects with the backing store once the requests complete.
Only the first synchronization can succeed. .NET simply discards the three extra session state objects and fires Session_End for each one. .NET does not attempt to synchronize the fifth session state object with the backing store because it was created for an asynchronous http module which is marked as requiring readonly session state.
So, the fix has two parts:
(1) In my Session_Start handler, I now check if the session state object is readonly. If it is, then I return immediately without doing anything. .NET will not fire a corresponding Session_End, and thus anything I do won't be cleaned up properly anyway.
(2) I now keep a reference count in my dictionary. I increment the count everytime a Session_Start handler tries to add a session id and decrement it everytime Session_End tries to remove one. Once the count reaches 0, I remove the session id from my dictionary.
answered Aug 3 '10 at 15:57
Peter Ruderman
10.1k2352
its a bit old.. but I'm not following why the 5 requests are in parallel. Is this spawned from a single request? Why are 5 created at the same time?
– Adam Tuliper - MSFT
Jun 7 '11 at 14:08
Multiple requests are created at the same time because the browser sends multiple requests without waiting for them to return. (After receiving the web page, the browser immediately requests all referenced images, style sheets, and so on.) The number 5 comes up because the machine was a Windows XP box. IIS limits applications to processing 5 simultaneous requests on desktop machines. On a server box, the number would have been higher.
– Peter Ruderman
Jun 9 '11 at 15:15
add a comment |
The answer to this question turned out to be fairly straight-foward, though the behaviour was certainly confusing.
Normally, MVC will synchronize all requests to an application on the application's session state lock (because MVC's http module is marked as requiring session state). In my scenario, the application restarts after serving the main page. Thus, when the main page-related requests come in, there is no session state for that session id yet and the requests execute in parallel.
I see 5 parallel requests because I'm developing on XP and desktop versions of IIS are limited to 5 concurrent requests. Since the session state object does not exist for any of these requests, each request creates a new session state object and fires Session_Start. Four of the requests go to MVC action methods. Since these require session state, .NET tries to synchronize the created session state objects with the backing store once the requests complete.
Only the first synchronization can succeed. .NET simply discards the three extra session state objects and fires Session_End for each one. .NET does not attempt to synchronize the fifth session state object with the backing store because it was created for an asynchronous http module which is marked as requiring readonly session state.
So, the fix has two parts:
(1) In my Session_Start handler, I now check if the session state object is readonly. If it is, then I return immediately without doing anything. .NET will not fire a corresponding Session_End, and thus anything I do won't be cleaned up properly anyway.
(2) I now keep a reference count in my dictionary. I increment the count everytime a Session_Start handler tries to add a session id and decrement it everytime Session_End tries to remove one. Once the count reaches 0, I remove the session id from my dictionary.
answered Aug 3 '10 at 15:57
Peter Ruderman
10.1k2352
The answer to this question turned out to be fairly straight-foward, though the behaviour was certainly confusing.
Normally, MVC will synchronize all requests to an application on the application's session state lock (because MVC's http module is marked as requiring session state). In my scenario, the application restarts after serving the main page. Thus, when the main page-related requests come in, there is no session state for that session id yet and the requests execute in parallel.
I see 5 parallel requests because I'm developing on XP and desktop versions of IIS are limited to 5 concurrent requests. Since the session state object does not exist for any of these requests, each request creates a new session state object and fires Session_Start. Four of the requests go to MVC action methods. Since these require session state, .NET tries to synchronize the created session state objects with the backing store once the requests complete.
Only the first synchronization can succeed. .NET simply discards the three extra session state objects and fires Session_End for each one. .NET does not attempt to synchronize the fifth session state object with the backing store because it was created for an asynchronous http module which is marked as requiring readonly session state.
So, the fix has two parts:
(1) In my Session_Start handler, I now check if the session state object is readonly. If it is, then I return immediately without doing anything. .NET will not fire a corresponding Session_End, and thus anything I do won't be cleaned up properly anyway.
(2) I now keep a reference count in my dictionary. I increment the count everytime a Session_Start handler tries to add a session id and decrement it everytime Session_End tries to remove one. Once the count reaches 0, I remove the session id from my dictionary.
answered Aug 3 '10 at 15:57
Peter Ruderman
10.1k2352
answered Aug 3 '10 at 15:57
Peter Ruderman
10.1k2352
answered Aug 3 '10 at 15:57
Peter Ruderman
10.1k2352
answered Aug 3 '10 at 15:57
Peter Ruderman
10.1k2352
10.1k2352
its a bit old.. but I'm not following why the 5 requests are in parallel. Is this spawned from a single request? Why are 5 created at the same time?
– Adam Tuliper - MSFT
Jun 7 '11 at 14:08
Multiple requests are created at the same time because the browser sends multiple requests without waiting for them to return. (After receiving the web page, the browser immediately requests all referenced images, style sheets, and so on.) The number 5 comes up because the machine was a Windows XP box. IIS limits applications to processing 5 simultaneous requests on desktop machines. On a server box, the number would have been higher.
– Peter Ruderman
Jun 9 '11 at 15:15
add a comment |
its a bit old.. but I'm not following why the 5 requests are in parallel. Is this spawned from a single request? Why are 5 created at the same time?
– Adam Tuliper - MSFT
Jun 7 '11 at 14:08
Multiple requests are created at the same time because the browser sends multiple requests without waiting for them to return. (After receiving the web page, the browser immediately requests all referenced images, style sheets, and so on.) The number 5 comes up because the machine was a Windows XP box. IIS limits applications to processing 5 simultaneous requests on desktop machines. On a server box, the number would have been higher.
– Peter Ruderman
Jun 9 '11 at 15:15
its a bit old.. but I'm not following why the 5 requests are in parallel. Is this spawned from a single request? Why are 5 created at the same time?
– Adam Tuliper - MSFT
Jun 7 '11 at 14:08
its a bit old.. but I'm not following why the 5 requests are in parallel. Is this spawned from a single request? Why are 5 created at the same time?
– Adam Tuliper - MSFT
Jun 7 '11 at 14:08
Multiple requests are created at the same time because the browser sends multiple requests without waiting for them to return. (After receiving the web page, the browser immediately requests all referenced images, style sheets, and so on.) The number 5 comes up because the machine was a Windows XP box. IIS limits applications to processing 5 simultaneous requests on desktop machines. On a server box, the number would have been higher.
– Peter Ruderman
Jun 9 '11 at 15:15
Multiple requests are created at the same time because the browser sends multiple requests without waiting for them to return. (After receiving the web page, the browser immediately requests all referenced images, style sheets, and so on.) The number 5 comes up because the machine was a Windows XP box. IIS limits applications to processing 5 simultaneous requests on desktop machines. On a server box, the number would have been higher.
– Peter Ruderman
Jun 9 '11 at 15:15
add a comment |
The session id can be reused if the client sends you a value that has expired. Read about the <sessionState> element's regenerateExpiredSessionId attribute here and notice that the default value is "true"
You might also find this interesting:
answered Jul 30 '10 at 13:05
matt-dot-net
3,8711623
Thanks for your reply Matt, but I believe I've been barking up the wrong tree. I'll update my question with some additional information I discovered yesterday.
– Peter Ruderman
Jul 30 '10 at 13:51
add a comment |
The session id can be reused if the client sends you a value that has expired. Read about the <sessionState> element's regenerateExpiredSessionId attribute here and notice that the default value is "true"
You might also find this interesting:
answered Jul 30 '10 at 13:05
matt-dot-net
3,8711623
Thanks for your reply Matt, but I believe I've been barking up the wrong tree. I'll update my question with some additional information I discovered yesterday.
– Peter Ruderman
Jul 30 '10 at 13:51
add a comment |
The session id can be reused if the client sends you a value that has expired. Read about the <sessionState> element's regenerateExpiredSessionId attribute here and notice that the default value is "true"
You might also find this interesting:
answered Jul 30 '10 at 13:05
matt-dot-net
3,8711623
The session id can be reused if the client sends you a value that has expired. Read about the <sessionState> element's regenerateExpiredSessionId attribute here and notice that the default value is "true"
You might also find this interesting:
answered Jul 30 '10 at 13:05
matt-dot-net
3,8711623
answered Jul 30 '10 at 13:05
matt-dot-net
3,8711623
answered Jul 30 '10 at 13:05
matt-dot-net
3,8711623
answered Jul 30 '10 at 13:05
matt-dot-net
3,8711623
3,8711623
Thanks for your reply Matt, but I believe I've been barking up the wrong tree. I'll update my question with some additional information I discovered yesterday.
– Peter Ruderman
Jul 30 '10 at 13:51
add a comment |
Thanks for your reply Matt, but I believe I've been barking up the wrong tree. I'll update my question with some additional information I discovered yesterday.
– Peter Ruderman
Jul 30 '10 at 13:51
Thanks for your reply Matt, but I believe I've been barking up the wrong tree. I'll update my question with some additional information I discovered yesterday.
– Peter Ruderman
Jul 30 '10 at 13:51
Thanks for your reply Matt, but I believe I've been barking up the wrong tree. I'll update my question with some additional information I discovered yesterday.
– Peter Ruderman
Jul 30 '10 at 13:51
add a comment |
I had this happen to me for an old ASP.NET app in development - turned out that RequireSSL was set to True for cookies... which of course meant that the session cookie wasn't kept/re-issued by the client (localhost, non SSL) - so subsequent requests created new session(s).
answered Dec 22 '15 at 11:41
Nathan
5,02322554
add a comment |
I had this happen to me for an old ASP.NET app in development - turned out that RequireSSL was set to True for cookies... which of course meant that the session cookie wasn't kept/re-issued by the client (localhost, non SSL) - so subsequent requests created new session(s).
answered Dec 22 '15 at 11:41
Nathan
5,02322554
add a comment |
I had this happen to me for an old ASP.NET app in development - turned out that RequireSSL was set to True for cookies... which of course meant that the session cookie wasn't kept/re-issued by the client (localhost, non SSL) - so subsequent requests created new session(s).
answered Dec 22 '15 at 11:41
Nathan
5,02322554
I had this happen to me for an old ASP.NET app in development - turned out that RequireSSL was set to True for cookies... which of course meant that the session cookie wasn't kept/re-issued by the client (localhost, non SSL) - so subsequent requests created new session(s).
answered Dec 22 '15 at 11:41
Nathan
5,02322554
answered Dec 22 '15 at 11:41
Nathan
5,02322554
answered Dec 22 '15 at 11:41
Nathan
5,02322554
answered Dec 22 '15 at 11:41
Nathan
5,02322554
5,02322554
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f3365942%2fwhy-does-my-asp-net-mvc-application-fire-session-start-multiple-times-for-a-sing%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What is it that you need to deal with? Are you saying there is a discrepancy between your dictionary and asp.net's internal dictionary? At what point are you finding the discrepancy?
– matt-dot-net
Jul 30 '10 at 17:41
Is the dictionary stored in an application variable or in a session variable?
– Joel Etherton
Jul 30 '10 at 19:38
The dictionary is an application variable.
– Peter Ruderman
Jul 30 '10 at 20:24
don't you use
Session_StartandSession_Endfor Count users ? WebFarm. Any source code samplefull?– PreguntonCojoneroCabrón
Nov 5 '16 at 12:55
I don't remember exactly what this was all about (it was 6 years ago), but the application was a web interface for a legacy system. There was no way around storing state and a web farm was not a scenario we had to consider. In the end, it turned out that IIS/MVC was a bad fit for us and we ended up reworking the application as a WCF REST service.
– Peter Ruderman
Nov 7 '16 at 17:16