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

On Tue, Mar 11, 2014 at 5:38 PM, Dale Henrichs <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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]> wrote:

On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <[hidden email]> 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

---

View this message in context: Re: Set session duration

Sent from the GLASS mailing list archive at Nabble.com.

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--
Mariano
http://marianopeck.wordpress.com