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

need guidance on users "session data" management.

P: n/a

I need to keep track on user "session data" while still turning session off
as
i do not want users login to expire?
Thanks

JB
Nov 19 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
You could store this information in a cookie written to the user's browser.
If there is much data to be stored you'd store some key in the cookie and
the rest in a database mapped to the key.

hope this helps,
mortb

"jensen bredal" <je***********@yahoo.dk> wrote in message
news:O8*************@TK2MSFTNGP15.phx.gbl...

I need to keep track on user "session data" while still turning session
off as
i do not want users login to expire?
Thanks

JB

Nov 19 '05 #2

P: n/a
Hi JB,

I think you will need to rethink your plan. There is a reason that Sessions
time out. Each Session has a certain amount of memory overhead associated
with it. If Sessions never time out, you've created a custom Memory Leak in
your app. Every time a Session is initiated, it adds to the memory overhead.
And with no way to remove a Session, the memory overhead keeps building
until your system is out of memory.

The reason that Sessions time out is that HTTP is stateless. Each Request
happens "in a vacuum" so to speak. The server has no way of knowing whether
or not the client is even there until it receives a Request. SessionState
was created to emulate statefullness for a given client. It (generally, by
default) creates a Session cookie on the client, which is sent with each
Request, identifying the Session (Memory block) that belongs to that client.
Once the client stops sending Requests, the Session kills itself after the
Timeout interval. The lack of Requests is the only way the server-side app
can know that the client has "gone away" so to speak.

There are methods you can employ to prevent Sessions timing out between
Requests, such as using a META Refresh tag on the client to re-Request the
page after an interval of < Session Timeout. Once the user navigates away
from the page, or closes their browser, it stops sending fresh Requests, and
the Server Session for that client times out and kills itself. Of course,
there are times when you don't want to send a fresh Request for the page, as
it may be in an "internediate" state (between PostBacks). In a case such as
that, you would use PostBacks to refresh the Session. This can be done using
client-side JavaScript and the JavaScript setTimeout() function.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"jensen bredal" <je***********@yahoo.dk> wrote in message
news:O8*************@TK2MSFTNGP15.phx.gbl...

I need to keep track on user "session data" while still turning session
off as
i do not want users login to expire?
Thanks

JB

Nov 19 '05 #3

P: n/a

"mortb" <mortb1<noospam<@hotmail.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
You could store this information in a cookie written to the user's
browser.
If there is much data to be stored you'd store some key in the cookie and
the rest in a database mapped to the key.

hope this helps,
mortb


Well thanks mortb,
My client uses governements pc and there very stric restriction on what can
be written to these pcs. No cookies allowed .
I described my senario in an early post but will recall it again.

One of my pages allow a pop up window wich in fact is a news bticker. It
holds an advanced dhtml rotator that scolls into database news.
It does refresh every hour.
It should not prompt users fo login again as the news ticker is supposed to
be
continuously running on users desks.

But i have not yet succeeded to achieve this.

My session times out although a refresh is issued before the session
expires.

so what to do in this case?

My purpose is not prompt users with login "again" a la "yahoo.com/mail"

Many thanks
JB
Nov 19 '05 #4

P: n/a
> I think you will need to rethink your plan. There is a reason that
Sessions time out. Each Session has a certain amount of memory overhead
associated with it. If Sessions never time out, you've created a custom
Memory Leak in your app. Every time a Session is initiated, it adds to the
memory overhead. And with no way to remove a Session, the memory overhead
keeps building until your system is out of memory.

Turning session off should hoppefully not creat memory leak?

The reason that Sessions time out is that HTTP is stateless. Each Request
happens "in a vacuum" so to speak. The server has no way of knowing
whether or not the client is even there until it receives a Request.
SessionState was created to emulate statefullness for a given client. It
(generally, by default) creates a Session cookie on the client, which is
sent with each Request, identifying the Session (Memory block) that
belongs to that client. Once the client stops sending Requests, the
Session kills itself after the Timeout interval. The lack of Requests is
the only way the server-side app can know that the client has "gone away"
so to speak.
Well i do refresh before the session is set to expire but, that does not
stop i from expiring.
What i'm i doing wrong?
There are methods you can employ to prevent Sessions timing out between
Requests, such as using a META Refresh tag on the client to re-Request the
page after an interval of < Session Timeout. Once the user navigates away
from the page, or closes their browser, it stops sending fresh Requests,
and the Server Session for that client times out and kills itself. Of
course, there are times when you don't want to send a fresh Request for
the page, as it may be in an "internediate" state (between PostBacks). In
a case such as that, you would use PostBacks to refresh the Session. This
can be done using client-side JavaScript and the JavaScript setTimeout()
function.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
What You Seek Is What You Get.

Nov 19 '05 #5

P: n/a
> Turning session off should hoppefully not creat memory leak?

No, but creating your own custom Session that doesn't time out will.
Well i do refresh before the session is set to expire but, that does not
stop i from expiring.
What i'm i doing wrong?


I have no idea. There's many a slip twixt the cup and the lip. IOW, you have
a bug in your code somewhere, but I don't know where, as I'm not psychic.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"jensen bredal" <je***********@yahoo.dk> wrote in message
news:up**************@TK2MSFTNGP14.phx.gbl...
I think you will need to rethink your plan. There is a reason that
Sessions time out. Each Session has a certain amount of memory overhead
associated with it. If Sessions never time out, you've created a custom
Memory Leak in your app. Every time a Session is initiated, it adds to
the memory overhead. And with no way to remove a Session, the memory
overhead keeps building until your system is out of memory.


Turning session off should hoppefully not creat memory leak?

The reason that Sessions time out is that HTTP is stateless. Each Request
happens "in a vacuum" so to speak. The server has no way of knowing
whether or not the client is even there until it receives a Request.
SessionState was created to emulate statefullness for a given client. It
(generally, by default) creates a Session cookie on the client, which is
sent with each Request, identifying the Session (Memory block) that
belongs to that client. Once the client stops sending Requests, the
Session kills itself after the Timeout interval. The lack of Requests is
the only way the server-side app can know that the client has "gone away"
so to speak.


Well i do refresh before the session is set to expire but, that does not
stop i from expiring.
What i'm i doing wrong?
There are methods you can employ to prevent Sessions timing out between
Requests, such as using a META Refresh tag on the client to re-Request
the page after an interval of < Session Timeout. Once the user navigates
away from the page, or closes their browser, it stops sending fresh
Requests, and the Server Session for that client times out and kills
itself. Of course, there are times when you don't want to send a fresh
Request for the page, as it may be in an "internediate" state (between
PostBacks). In a case such as that, you would use PostBacks to refresh
the Session. This can be done using client-side JavaScript and the
JavaScript setTimeout() function.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
What You Seek Is What You Get.


Nov 19 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.