Session expiration and data cleaning
Locked
 
|
Hi,
I need to clear some data on session expiration. After several searches and attempts I discovered that sessions expired after #cacheTimeout but they are unregistered only after the creation of 10 more sessions, see here: http://lists.squeakfoundation.org/pipermail/seaside/2010-June/023663.html and http://lists.squeakfoundation.org/pipermail/seaside/2010-June/023670.html you can change it reducing the cacheReapInterval, for example if you want to unregister your session after 2 sessions are created, you can write: myApplication cache reapingStrategy configuration at:#cacheReapInterval put: 2. and you can test it creating a MySession: MySession>>unregistered super unregistered. Time now inspect. then associate it to your application: myApplication preferenceAt: #sessionClass put: MySession. and looking at the time of inspection, so far so good. But... I need to clean my data when the session expires (with or without a timeout), not when the session expires *and* after 2 or more sessions are created. Have you any suggestion? TIA Dave |
|
|
No hint?
Dave |
Re: Session expiration and data cleaning
|
i thought that’s not 10 created sessions but 10 queries to the cache. You can also create a background timer and let it access the application’s cache and trigger a reap.
Kind Regards Karsten -- Karsten Kusche - Dipl. Inf. - [hidden email] Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 Am Dienstag, 25. Februar 2014 um 08:40 schrieb Dave:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi,
it seems this is a common request, because it pops up from time to time. Seems people are unhappy about the fact that the time sessions may exist after their expiry is undefined. So what Karsten describes is probably a feature request... For our application we decided to design our session classes to not hold on to critical resources for longer that they need them, so that their lingering after expiry is not an issue. For peace of mind, it would be nicer if sessions just got killed once they've expired. Joachim Am 25.02.14 08:45, schrieb Karsten Kusche:
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel [hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi, Maybe I am stupid, but if you depend on your sessions to expire to release key resources, I think this always means you have a security hazard. One should not rely on what the user does or does not. So I think the question should be: why is it important to know the exact time the session expires? What data do you need to clear, that it cannot wait to be cleared? On 25 Feb 2014, at 08:53, [hidden email] wrote:
On 24 Feb 2014, at 11:39, Dave <[hidden email]> wrote: Hi, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi Diego,
My case I don't need an exact time of session expiration, that's fine for my goal, but if you try my code you'll realize if more sessions aren't created MySession>>unregistered is not called even if the session is expired, so data won't clear ever Dave
|
|
|
In reply to this post by Karsten Kusche
Karsten,
I'll try your hint thanks Dave
|
Re: Session expiration and data cleaning
|
|
I run into similar problems with seaside sessions and expiry. but mainly during development as my image grows in size. It would be very handy to have a utility or method that will actively expire and/or remove all sessions on demand such that I can do the following:WASession allInstances size "print" -> 0 On Tue, Feb 25, 2014 at 8:39 AM, Dave <[hidden email]> wrote: Karsten, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Session expiration and data cleaning
|
|
I wonder if this doesn't point the way...
expire self greaseDeprecatedApi: 'WASession>>#expire' details: 'This method might be reimplemented again. In the meantime, if you just want to remove the Session from the Application, use WASession>>unregister (#unregistered will be called as a notification instead of #expired). Otherwise you should consider adding a Request Filter to the Session that implements whatever behaviour you want in order to block access to the Session.'. ^ self unregister as well as... WACache allInstances do: [ :e | e reap]. Cheers, Bob On 2/25/14 1:03 PM, Jon Paynter wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Session expiration and data cleaning
|
|
On Tue, Feb 25, 2014 at 7:19 PM, Bob Arning <[hidden email]> wrote:
> I wonder if this doesn't point the way... > > expire > self > greaseDeprecatedApi: 'WASession>>#expire' > details: 'This method might be reimplemented again. In the meantime, > if you just want to remove the Session from the Application, use > WASession>>unregister (#unregistered will be called as a notification > instead of #expired). Otherwise you should consider adding a Request Filter > to the Session that implements whatever behaviour you want in order to block > access to the Session.'. > ^ self unregister > > as well as... > > WACache allInstances do: [ :e | e reap]. What problem exactly are you trying to solve? Do you have to do some work when the session expires? It is true that per default we only expire on every n-th session creation. You can change this by swapping the reapingStrategy WAAccessIntervalReapingStrategy. However keep in mind that: - if somebody just creates sessions but never accesses them you may still want to reap at some point - reaping does not scale well, you have to walk over all the sessions We are aware that the current situation is suboptimal and are working on a replacement [1] but that may take a moment. [1] http://lists.squeakfoundation.org/pipermail/seaside-dev/2014-February/005710.html Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Session expiration and data cleaning
|
|
Umm, my reply was to Jon Paynter's message
which was basically how to clean up during development. Whether
someone finds some applicability to post-development scenarios,
well, YMMV.
Cheers, Bob On 2/26/14 12:48 PM, Philippe Marschall
wrote:
On Tue, Feb 25, 2014 at 7:19 PM, Bob Arning [hidden email] wrote: _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Session expiration and data cleaning
|
|
ive tried WASession allInstances do: [ : item | item unregister]. and various other permutations.
On Wed, Feb 26, 2014 at 10:00 AM, Bob Arning <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Session expiration and data cleaning
|
|
You might try
PointerFinder on: WASession allInstances first Cheers, Bob On 2/26/14 2:09 PM, Jon Paynter wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Session expiration and data cleaning
|
|
that looks promising - where do get PointerFinder? its not in my VisualWorks image. On Wed, Feb 26, 2014 at 11:34 AM, Bob Arning <[hidden email]> wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Session expiration and data cleaning
|
|
Ah, well. It's a squeak thing. Perhaps VW has
something similar.
Cheers, Bob On 2/26/14 2:49 PM, Jon Paynter wrote:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Bob Arning-2
Thanks Bob,
WACache allInstances do: [ :e | e reap] is right for my needs. Now I have to tune a timer, as Karsten already pointed out and I think I can solve my issues. Thanks guys Cheers Dave
|
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |