WAApplication and WASession subclassing and expiry, again

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

WAApplication and WASession subclassing and expiry, again

Tim Johnson-2
Hi,

The current recommended practice seems to be to subclass WAApplication[1][5][6] especially if one wants to handle session expiration/expiry[2].  One must then register the WAApplication as the application root, and use other tricks (override another method) to get one's component (or task) into the flow [3], it seems.  

I am a student of the HPI book[4] (since many years ago) which trains me to keep all of my application logic (model) in my custom WASession subclass.  If I am to also subclass WAApplication, am I to move all of my application logic to that instead[7]?  

I ask because I am recently dealing with the first Seaside app I have deployed to the wider internet (instead of an intranet), and sessions are not expiring, a'la [4].  They will stick around for days.  My app also seems to lock up after about 24 hours which is getting annoying.  :)     

When I look at implementors and senders of #unregistered[8], I see that perhaps I should now be subclassing WAExpirySession instead of WASession if I want my sessions to expire (or if I want to hook into the expiration process)...?  I cannot find much documentation on the net regarding WAExpirySession.

Also, I am on Seaside 3.2.2 — might it help to upgrade?

Thanks,
Tim










_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: WAApplication and WASession subclassing and expiry, again

Tim Johnson-2
Sorry, HPI book link:  http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial



On May 19, 2019, at 9:01 AM, Tim Johnson <[hidden email]> wrote:

Hi,

The current recommended practice seems to be to subclass WAApplication[1][5][6] especially if one wants to handle session expiration/expiry[2].  One must then register the WAApplication as the application root, and use other tricks (override another method) to get one's component (or task) into the flow [3], it seems.  

I am a student of the HPI book[4] (since many years ago) which trains me to keep all of my application logic (model) in my custom WASession subclass.  If I am to also subclass WAApplication, am I to move all of my application logic to that instead[7]?  

I ask because I am recently dealing with the first Seaside app I have deployed to the wider internet (instead of an intranet), and sessions are not expiring, a'la [4].  They will stick around for days.  My app also seems to lock up after about 24 hours which is getting annoying.  :)     

When I look at implementors and senders of #unregistered[8], I see that perhaps I should now be subclassing WAExpirySession instead of WASession if I want my sessions to expire (or if I want to hook into the expiration process)...?  I cannot find much documentation on the net regarding WAExpirySession.

Also, I am on Seaside 3.2.2 — might it help to upgrade?

Thanks,
Tim









_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: WAApplication and WASession subclassing and expiry, again

Johan Brichau-2
In reply to this post by Tim Johnson-2
Hi Tim,

Unless you want to share state across all your sessions, you should not be subclassing WAApplication.

Default Seaside configuration comes with WALastAccessExpiryPolicy configured at 600 seconds, which removes sessions from the session cache when they have not been accessed for more than 10 minutes.
This is done every time Seaside serves a request.

If you override NPSession>>unregistered you can perform specific actions when the session is unregistered.
Mind that you _must_ make a supercall in that override, or your sessions will not be removed.

WAExpirySession is just an example where the unregistration and registration is counted. It does nothing special.

If your sessions do not expire, it would be helpful to know what your config is.

cheers
Johan

On 19 May 2019, at 18:01, Tim Johnson <[hidden email]> wrote:

Hi,

The current recommended practice seems to be to subclass WAApplication[1][5][6] especially if one wants to handle session expiration/expiry[2].  One must then register the WAApplication as the application root, and use other tricks (override another method) to get one's component (or task) into the flow [3], it seems.  

I am a student of the HPI book[4] (since many years ago) which trains me to keep all of my application logic (model) in my custom WASession subclass.  If I am to also subclass WAApplication, am I to move all of my application logic to that instead[7]?  

I ask because I am recently dealing with the first Seaside app I have deployed to the wider internet (instead of an intranet), and sessions are not expiring, a'la [4].  They will stick around for days.  My app also seems to lock up after about 24 hours which is getting annoying.  :)     

When I look at implementors and senders of #unregistered[8], I see that perhaps I should now be subclassing WAExpirySession instead of WASession if I want my sessions to expire (or if I want to hook into the expiration process)...?  I cannot find much documentation on the net regarding WAExpirySession.

Also, I am on Seaside 3.2.2 — might it help to upgrade?

Thanks,
Tim









_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside