need guidance on users "session data" management.

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

re: need guidance on users "session data" management.

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" <jensen.bredal@yahoo.dk> wrote in message
news:O8vShTzRFHA.576@TK2MSFTNGP15.phx.gbl...[color=blue]
>
> 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
>[/color]

re: need guidance on users "session data" management.

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" <jensen.bredal@yahoo.dk> wrote in message
news:O8vShTzRFHA.576@TK2MSFTNGP15.phx.gbl...[color=blue]
>
> 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
>[/color]

re: need guidance on users "session data" management.

"mortb" <mortb1<noospam<@hotmail.com> wrote in message
news:%23mxZTjzRFHA.3144@tk2msftngp13.phx.gbl...[color=blue]
> 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
>[/color]

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

re: need guidance on users "session data" management.

> I think you will need to rethink your plan. There is a reason that[color=blue]
> 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.
>[/color]

Turning session off should hoppefully not creat memory leak?

[color=blue]
> 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.[/color]

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?
[color=blue]
> 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.[/color]

re: need guidance on users "session data" management.

> Turning session off should hoppefully not creat memory leak?

No, but creating your own custom Session that doesn't time out will.
[color=blue]
> 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?[/color]

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" <jensen.bredal@yahoo.dk> wrote in message
news:upy5LX0RFHA.2136@TK2MSFTNGP14.phx.gbl...[color=blue][color=green]
>> 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.
>>[/color]
>
> Turning session off should hoppefully not creat memory leak?
>
>[color=green]
>> 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.[/color]
>
> 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?
>[color=green]
>> 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.[/color]
>
>[/color]