[Seaside] Re: Session expiration and data cleaning
arning315 at comcast.net
Wed Feb 26 18:00:56 UTC 2014
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.
On 2/26/14 12:48 PM, Philippe Marschall wrote:
> On Tue, Feb 25, 2014 at 7:19 PM, Bob Arning <arning315 at comcast.net> wrote:
>> I wonder if this doesn't point the way...
>> 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  but that may take a moment.
>  http://lists.squeakfoundation.org/pipermail/seaside-dev/2014-February/005710.html
> seaside mailing list
> seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside