mcantone at skarven
Oct 6, 2004, 8:39 AM
Post #3 of 5
(1757 views)
Permalink
|
Thanks - you've confirmed everything I suspected.
-Mike
Fagyal Csongor wrote:
> Hi Mike,
>
>> I need a better understanding of when a session gets created as
>> opposed to when an existing session is used.
>>
>> Let me put forth my understanding and if someone can tell me where I'm
>> right/wrong I'd greatly appreciate it.
>>
>> OBSERVATIONS
>>
>> I've observed the following behavior.
>>
>> * On mozilla, if I bring up my application on multiple tags of the
>> same browser instance, it all seems to access the same session
>> (assuming I haven't abandoned it).
>> * With mozilla, on the same client, if I bring up multiple versions of
>> mozilla, it seems to tap into different sessions.
>> * With konqueror (which I must support), from the same hardware
>> client, even with different instances of the browser, it seems to tap
>> into the same session.
>> * From different hardware clients, it always seems to create a new
>> session or tap into an existing session from that same client).
>
> .
> This all boils down to how cookies behave. If you understand how cookies
> work, you will understand sessions, too (probably, at least).
>
>> SESSION MECHANICS THEORY
>>
>> So, my theory based on these observations is that a cookie defines a
>> session and that cookie always has the exact name "session-id" and,
>> for some reason mozilla must maintain separate caches of cookies per
>> browser invocation will mozilla does not.
>
>
> So you do understand cookies :-)
>
>> QUESTIONS
>>
>> * Is there any way to have more than one session for a given hardware
>> client perhaps based on application?
>
>
> I don't fully understand this question, but you might try to use
> cookie-less sessions using URL rewriting. This way you are not bound to
> how different browsers/browser instances handle cookies. But you must
> take care of session initialization (creating new sessions) at
> corresponding pages.
>
>> That would imply either the session-id cooke could be prefixed or
>> somehow the browser would store it in a subdirectory based on the
>> application (I don't know if browsers allow this type of control
>> within the cookie directory though I'm scpetical the sub-directory
>> thing is feasible).
>
>
>> * With regard to session timeout, if it is set to something like 60
>> minutes, is that 60 minutes from the beginning of session creation or
>> 60 minutes from the point of last activity. The latter seems more
>> useful and typical to me, but I'd like to confirm it...
>
>
> Last activity.
>
>> * Our application is characterized by few simultaneous users that
>> perform tasks where there is significant computation. While the
>> computation generates a fair amount of data (a few MB), the
>> computation takes long enough that it is highly desirable to keep the
>> results in session. Is there a limit to how much data I can keep in
>> session?
>
>
> Depends on what kind of session storage you use. See:
> http://www.apache-asp.org/config.html#StateDB
> IMHO the default state manager can only handle 1k or so - others can
> hold much more data.
>
>> Based on how our applicaiton is characterized is there any reason to
>> not keep the data in session?
>
>
> Session data is stored on disc. Because of this, on every page where you
> use the session it must be fetched, which might slow down you
> application and increase the memory usage of your application.
>
> Hope this helps.
>
> - Csongor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe [at] perl
> For additional commands, e-mail: asp-help [at] perl
>
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl
|
