[Glass] [GS/SS Beta] Set session duration

Dale Henrichs dale.henrichs at gemtalksystems.com
Tue Mar 11 13:38:14 PDT 2014


Mariano,

I haven't delved into the timeouts for quite some time, so this is from
memory and I could be completely wrong:).

IIRC, there are two caches that are two caches that are subject to
timeouts: the session cache and "continuation cache" ... when the session
is timed out, the session itself is no longer accessible ...

The "continuation cache" manages the lifetime of individual link
continuations for a particular page and when a continuation is timed out
that particular link is no longer accessible while the session and other
links are still available ...

the mtce vm process is responsible for timing out both the session cache
and continuation cache (see WABasicDevelopment
class>>reapHandlerCache:dispatchers:) and the reaping is done via the
message gemstoneReap ....

GemStone uses the WARcLastAccessExpiryPolicy and this should not be changed
as the reduced conflict aspect is important for GemStone ... if other types
of Expiry polices are needed, they just need to be made RC ... the
implication of this is that  timeout is used to determine expiration...

I think that standard Seaside uses a different scheme (least recently
used?) for continuations and I seem to recall that a count of some kind was
involved (not sure about this bit) ...

The timeout will impact links from the aspect that if a link isn't used
during the timeout period it will be reaped while the session itself can
continue to live as long as it has been accessed so continuations are not
kept alive for the duration of a session ...

Given this information I can't think of a reason why you would need to set
the timeout for continuations less than the session timeout and I don't
think it makes sense to set the continuation timeout longer than the
session timeout, since I don't think that old links are in danger of being
accessed past the link timeout ...

Dale




On Tue, Mar 11, 2014 at 12:53 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

> Hi guys,
>
> I am reviving this old thread because I have been caught by the same
> problem. In my case, I wanted to expire at the same time I have defined for
> the app (moreover, same session class could be used in different apps with
> different expiration times). Also, I wanted to use the same session class
> for Pharo and for GemStone. So what I did was to implement:
>
> MyWASessionSubclass >> setParent: aRequestHandler
> super setParent: aRequestHandler.
> continuations expiryPolicy configuration attributeAt: #cacheTimeout
> ifAbsent: [ ^ self ].
>  continuations expiryPolicy configuration attributeAt: #cacheTimeout put:
> (aRequestHandler cache expiryPolicy configuration at: #cacheTimeout).
>
>
> I couldn't use the #initialize because at that point my app was not yet
> set..and I wanted to grab the timeout from there.  The ugly IF is just so
> that it works in Pharo as well....
>
> Now...the question is...what is this timeout of continuations? How does it
> impacts me as a developer? it is correct to set the same time as the app?
> From my tests it does seem the case, but I just wonder....
>
> Thanks in advance,
>
>
>
>
> On Mon, Apr 23, 2012 at 9:19 AM, keropotter <keropotter at gmail.com> wrote:
>
>> Yes, that's what Dale suggested and it worked perfectly.
>>
>> Thank you!!
>> Ale
>>
>> On Sun, Apr 22, 2012 at 10:58 AM, Philippe Marschall [via Smalltalk] <[hidden
>> email] <http://user/SendEmail.jtp?type=node&node=4580243&i=0>> wrote:
>>
>>> On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <[hidden email]<http://user/SendEmail.jtp?type=node&node=4578211&i=0>>
>>> wrote:
>>> > It doesn't look like there is any way to actually control the timeout
>>> used by the continuation cache without directly editing the code. The
>>> WASession>>createCache method looks like the following:
>>> >
>>>
>>> Subclassing WASession and overriding #createCache should work.
>>>
>>> Cheers
>>> Philippe
>>>
>>>
>>> ------------------------------
>>>  If you reply to this email, your message will be added to the
>>> discussion below:
>>> http://forum.world.st/Set-session-duration-tp4553027p4578211.html
>>>  To unsubscribe from Set session duration, click here.
>>> NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>
>>
>>
>> ------------------------------
>> View this message in context: Re: Set session duration<http://forum.world.st/Set-session-duration-tp4553027p4580243.html>
>>
>> Sent from the GLASS mailing list archive<http://forum.world.st/GLASS-f1460844.html>at Nabble.com.
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140311/76f8cf1c/attachment.html>


More information about the Glass mailing list