Kill And ASP.NET Session

[Goofy]

Does anyone know how I can kill a session by session ID ?
--
Goofy

[Goofy]

Yes, I understand this. The problem I have is when users who close and
reopen the application several times and each time they generate new
sessions and consume resources.

What really need is to invoke something like to be run from session start.
Note Each time I start a session I log the username and session ID in a
table. Each time the session ends I delete the record for that user /
session ID. So on session start

If CheckSessionDatabaseRecordExists( Session("userName")
,Session("sessionID") ) then
DeleteSessionDatabaseRecord(Session("userName"),Se ssion("sessionID")

'//This is what I need
Session.kill(SessionID)
'//

End if

this would fire the session end event for that particular session and
release its state storage etc.

Cheers

"Manish Bafna" <Ma*********@discussions.microsoft.comwrote in message
news:6A**********************************@microsof t.com...

Hi,
I have read that unless you have configured to use cookieless session,the
ASP.NET by default uses cookies to maintain sessions.In fact cookie with
name
of sessionid is created on hard disk.So if we delete this cookie i think
we
would be able to abandon session by sessionid.Find below MSDN
Documentation
on how to delete cookie from user's machine:
Deleting a cookie-physically removing it from the user's hard disk-is a
variation on modifying it. You cannot directly remove a cookie because the
cookie is on the user's computer. However, you can have the browser delete
the cookie for you. The technique is to create a new cookie with the same
name as the cookie to be deleted, but to set the cookie's expiration to a
date earlier than today. When the browser checks the cookie's expiration,
the
browser will discard the now-outdated cookie. The following code example
shows one way to delete all the cookies available to the application:

C# Copy Code
HttpCookie aCookie;
string cookieName;
int limit = Request.Cookies.Count;
for (int i=0; i<limit; i++)
{
cookieName = Request.Cookies[i].Name;
aCookie = new HttpCookie(cookieName);
aCookie.Expires = DateTime.Now.AddDays(-1);
Response.Cookies.Add(aCookie);
}

Thanks and Regards,
Manish Bafna.
MCP and MCTS

"Goofy" wrote:

>Does anyone know how I can kill a session by session ID ?
--
Goofy

[Mark Rae]

"Goofy" <[e-mail] in message
news:uK*************@TK2MSFTNGP02.phx.gbl...

Yes, I understand this. The problem I have is when users who close and
reopen the application several times and each time they generate new
sessions and consume resources.

Yes, that's right - this behaviour is by design - hack about with it at your
peril...!

What really need is to invoke something like to be run from session
start. Note Each time I start a session I log the username and session ID
in a table. Each time the session ends I delete the record for that user /
session ID. So on session start

If CheckSessionDatabaseRecordExists( Session("userName")
,Session("sessionID") ) then

As you correctly state above, closing and re-opening the application
generates a *new* session. As a *new* session will have a *new* SessionID
(OK, this isn't absolutely always the case in every single scenario, but it
almost always is), surely the above code will (almost) never return True
because the new session will (almost) always have a new SessionID...?

'//This is what I need
Session.kill(SessionID)
'//

Every single method of the Session object operates on the *current*
session - there is no mechanism for passing in a SessionID...
http://msdn2.microsoft.com/en-gb/library/ms524319.aspx

[Juan T. Llibre]

If you mean from outside the session itself ( like in another application ), you can't.

If from within the same session : Session.Abandon


Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
"Goofy" <[e-mail] in message news:ur**************@TK2MSFTNGP02.phx.gbl...

Does anyone know how I can kill a session by session ID ?
Goofy

[Goofy]

In my scenario, each time a user gets a new session, they get a record in
the whosOn table which records the time, userName and session ID.

So they access the application, close the window and access the application
again before the first session times out two sessions would be recorded in
whosOn. My mistake on the function, it should have read.

If CheckSessionDatabaseRecordExists( Session("userName") Then

eithe kill the session for that record or simply delete it from the
database

End If

Now created the new record.

The approach I have taken in light of what you say and what I have read, is
that I simply delete the previous records with the same username before
creating a new one. When the old sessions time out there will be nothing for
them to delete.

It would be tidier though if you could kill the old sessions to preserve
resources. Its perhaps not so important in small applications, but when
there are hundreds of users on line, this could lead to problems.

Thanks for your input though.

>>
If CheckSessionDatabaseRecordExists( Session("userName")
,Session("sessionID") ) then

As you correctly state above, closing and re-opening the application
generates a *new* session. As a *new* session will have a *new* SessionID
(OK, this isn't absolutely always the case in every single scenario, but
it almost always is), surely the above code will (almost) never return
True because the new session will (almost) always have a new SessionID...?

> '//This is what I need
Session.kill(SessionID)

[Robbe Morris [C# MVP]]

If you use this product to manage session (the license may be free
if you only have one server), you can definitely do this.

It supports in memory session access from within or
outside the individual session. You can also share session
in memory across servers on a farm and application domains.

It basically gives you way to create a unique key and reference
what is stored under that key from any app on any server
regardless of application domain.

http://www.eggheadcafe.com/articles/scaleout_server.asp

--
Robbe Morris - 2004-2006 Microsoft MVP C#
I've mapped the database to .NET class properties and methods to
implement an multi-layered object oriented environment for your
data access layer. Thus, you should rarely ever have to type the words
SqlCommand, SqlDataAdapter, or SqlConnection again.
http://www.eggheadcafe.com/articles/..._generator.asp

"Goofy" <[e-mail] in message
news:ur**************@TK2MSFTNGP02.phx.gbl...

Does anyone know how I can kill a session by session ID ?
--
Goofy

[Goofy]

I'll take a look, thanks for your help.

"Robbe Morris [C# MVP]" <jo*****@joe.comwrote in message
news:B8**********************************@microsof t.com...

If you use this product to manage session (the license may be free
if you only have one server), you can definitely do this.

It supports in memory session access from within or
outside the individual session. You can also share session
in memory across servers on a farm and application domains.

It basically gives you way to create a unique key and reference
what is stored under that key from any app on any server
regardless of application domain.

http://www.eggheadcafe.com/articles/scaleout_server.asp

--
Robbe Morris - 2004-2006 Microsoft MVP C#
I've mapped the database to .NET class properties and methods to
implement an multi-layered object oriented environment for your
data access layer. Thus, you should rarely ever have to type the words
SqlCommand, SqlDataAdapter, or SqlConnection again.
http://www.eggheadcafe.com/articles/..._generator.asp

"Goofy" <[e-mail] in message
news:ur**************@TK2MSFTNGP02.phx.gbl...

>Does anyone know how I can kill a session by session ID ?
--
Goofy

[Mark Rae]

"Goofy" <[e-mail] in message
news:u5**************@TK2MSFTNGP03.phx.gbl...

It would be tidier though if you could kill the old sessions to preserve
resources. Its perhaps not so important in small applications, but when
there are hundreds of users on line, this could lead to problems.

Several options, then:

1) Make the sessions as small as possible

2) Reduce the Session.Timeout from its default of 20 minutes

3) Add more memory to your webserver

4) Use SQL Server to manage state instead of InProc

[Goofy]

I dont think option (2) will go down too well, so initially I think option
(3) is the quick and easy answer as option (4) may have its own inherent
problems.

I've heard of strange things happening when state is not managed inproc.
(not saying it cant work ), but no point in adding extra risk if I can avoid
it.

Thanks for your help.
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

"Goofy" <[e-mail] in message
news:u5**************@TK2MSFTNGP03.phx.gbl...

>It would be tidier though if you could kill the old sessions to preserve
resources. Its perhaps not so important in small applications, but when
there are hundreds of users on line, this could lead to problems.

Several options, then:

1) Make the sessions as small as possible

2) Reduce the Session.Timeout from its default of 20 minutes

3) Add more memory to your webserver

4) Use SQL Server to manage state instead of InProc

[Mark Rae]

"Goofy" <[e-mail] in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

I dont think option (2) will go down too well,

You might be pleasantly surprised, in fact...

so initially I think option (3) is the quick and easy answer

Well, it's certainly quick and easy - if you are maxed out on your server's
RAM capacity, you could always look at throwing more hardware at the problem
by getting more servers and using NLBS...

as option (4) may have its own inherent problems.

Such as...?

I've heard of strange things happening when state is not managed inproc.

Like what...?

(not saying it cant work )

Well, obviously it *can* work otherwise it wouldn't be there...

[Juan T. Llibre]

re:

>as option (4) may have its own inherent problems.

Such as...?

>I've heard of strange things happening when state is not managed inproc.

Like what...?

Like Session_End not firing... ?


Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message news:%2****************@TK2MSFTNGP03.phx.gbl...

"Goofy" <[e-mail] in message news:%2****************@TK2MSFTNGP04.phx.gbl...

>I dont think option (2) will go down too well,

You might be pleasantly surprised, in fact...

>so initially I think option (3) is the quick and easy answer

Well, it's certainly quick and easy - if you are maxed out on your server's RAM capacity, you
could always look at throwing more hardware at the problem by getting more servers and using
NLBS...

>as option (4) may have its own inherent problems.

Such as...?

>I've heard of strange things happening when state is not managed inproc.

Like what...?

>(not saying it cant work )

Well, obviously it *can* work otherwise it wouldn't be there...

[Mark Rae]

"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

>>I've heard of strange things happening when state is not managed inproc.

Like what...?

Like Session_End not firing... ?

Yes indeed, but that's by design, not strange or unexpected...

[Juan T. Llibre]

re:

Yes indeed, but that's by design, not strange or unexpected...

heh, heh...

I find some "by design" behaviors quite strange.

;-)


Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message news:uk**************@TK2MSFTNGP06.phx.gbl...

"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...

>>>I've heard of strange things happening when state is not managed inproc.
Like what...?

Like Session_End not firing... ?

Yes indeed, but that's by design, not strange or unexpected...

[Mark Rae]

"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

re:

>Yes indeed, but that's by design, not strange or unexpected...

heh, heh...

I find some "by design" behaviors quite strange.

;-)

Ah yes, but that's a different argument... :-)

E.g. why doesn't HttpWebRequest implement IDisposable...? Did they just
forget...?