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

Tue Mar 11 14:04:19 PDT 2014

On Tue, Mar 11, 2014 at 5:38 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> 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 ...
>
>
Yes..that was what was happening to me. I had the main component of my app
(the one that is present at anytime) and if I click in any menu or
something then I was kickoff. But what can I do if it is not clicking or
doing something?

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

Exactly!!!! That was my reasoning too...but then I wonder why the
continuations time out existed at all ;)

Thanks,

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

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140311/0869b006/attachment-0001.html>