need guidance on users "session data" management.

[jensen bredal]

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

[mortb]

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

[Kevin Spencer]

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

[jensen bredal]

"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

[jensen bredal]

> 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.

[Kevin Spencer]

> 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.