Session expiration and data cleaning

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

Session expiration and data cleaning

Dave
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
Reply | Threaded
Open this post in threaded view
|

Re: Session expiration and data cleaning

Dave
No hint?

Dave
Reply | Threaded
Open this post in threaded view
|

Re: Session expiration and data cleaning

Karsten Kusche
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:

No hint?

Dave



--
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list


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

Re: Session expiration and data cleaning

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

No hint?

Dave



--
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list



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


-- 
-----------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Re: Session expiration and data cleaning

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

Diego

On 25 Feb 2014, at 08:53, [hidden email] wrote:

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

No hint?

Dave



--
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
seaside mailing list

On 24 Feb 2014, at 11:39, Dave <[hidden email]> wrote:

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


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

Re: Session expiration and data cleaning

Dave
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

DiegoLont wrote
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?

Diego

On 25 Feb 2014, at 08:53, [hidden email] wrote:

> 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:
>> 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:
>>
>>> No hint?
>>>
>>> Dave
>>>
>>>
>>>
>>> --
>>> View this message in context: http://forum.world.st/Session-expiration-and-data-cleaning-tp4745919p4746106.html
>>> Sent from the Seaside General mailing list archive at Nabble.com.
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
On 24 Feb 2014, at 11:39, Dave <[hidden email]> wrote:

> 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


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

Re: Session expiration and data cleaning

Dave
In reply to this post by Karsten Kusche
Karsten,
I'll try your hint
thanks
Dave

Karsten Kusche wrote
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] (mailto:[hidden email])
Georg Heeg eK - Köthen  
Handelsregister: Amtsgericht Dortmund A 12812


Am Dienstag, 25. Februar 2014 um 08:40 schrieb Dave:

> No hint?
>  
> Dave
>  
>  
>  
> --
> View this message in context: http://forum.world.st/Session-expiration-and-data-cleaning-tp4745919p4746106.html
> Sent from the Seaside General mailing list archive at Nabble.com (http://Nabble.com).
> _______________________________________________
> seaside mailing list
> [hidden email] (mailto:[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: Session expiration and data cleaning

Jon Paynter-2
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" -> some number
< run some code >
< run garbage collection >
WASession allInstances size "print" -> 0






On Tue, Feb 25, 2014 at 8:39 AM, Dave <[hidden email]> wrote:
Karsten,
I'll try your hint
thanks
Dave


Karsten Kusche wrote
> 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. -

> karsten@

>  (mailto:

> karsten@

> )
> Georg Heeg eK - Köthen
> Handelsregister: Amtsgericht Dortmund A 12812
>
>
> Am Dienstag, 25. Februar 2014 um 08:40 schrieb Dave:
>
>> No hint?
>>
>> Dave
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Session-expiration-and-data-cleaning-tp4745919p4746106.html
>> Sent from the Seaside General mailing list archive at Nabble.com
>> (http://Nabble.com).
>> _______________________________________________
>> seaside mailing list
>>

> seaside@.squeakfoundation

>  (mailto:

> seaside@.squeakfoundation

> )
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
>
>
> _______________________________________________
> seaside mailing list

> seaside@.squeakfoundation

> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside





--
View this message in context: http://forum.world.st/Session-expiration-and-data-cleaning-tp4745919p4746303.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
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: Session expiration and data cleaning

Bob Arning-2
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:
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" -> some number
< run some code >
< run garbage collection >
WASession allInstances size "print" -> 0






On Tue, Feb 25, 2014 at 8:39 AM, Dave <[hidden email]> wrote:
Karsten,
I'll try your hint
thanks
Dave


Karsten Kusche wrote
> 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. -

> karsten@

>  (mailto:

> karsten@

> )
> Georg Heeg eK - Köthen
> Handelsregister: Amtsgericht Dortmund A 12812
>
>
> Am Dienstag, 25. Februar 2014 um 08:40 schrieb Dave:
>
>> No hint?
>>
>> Dave
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Session-expiration-and-data-cleaning-tp4745919p4746106.html
>> Sent from the Seaside General mailing list archive at Nabble.com
>> (http://Nabble.com).
>> _______________________________________________
>> seaside mailing list
>>

> [hidden email]

>  (mailto:

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





--
View this message in context: http://forum.world.st/Session-expiration-and-data-cleaning-tp4745919p4746303.html
Sent from the Seaside General mailing list archive at Nabble.com.
_______________________________________________
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


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

Re: Session expiration and data cleaning

Philippe Marschall
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
Reply | Threaded
Open this post in threaded view
|

Re: Session expiration and data cleaning

Bob Arning-2
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:
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



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

Re: Session expiration and data cleaning

Jon Paynter-2
ive tried WASession allInstances do: [ : item | item unregister].
and various other permutations.

Some sessions go away, but most do not.  So something else is hanging onto the sessions.  Eventually I will get fed up with my bloated image and reload everything from source.

If there is a reasonable way to track what is holding onto the sessions i can track that down and either fix my own bugs, or submit a new one here to the list.



On Wed, Feb 26, 2014 at 10:00 AM, Bob Arning <[hidden email]> wrote:
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:
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



_______________________________________________
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: Session expiration and data cleaning

Bob Arning-2
You might try

PointerFinder on: WASession allInstances first

Cheers,
Bob

On 2/26/14 2:09 PM, Jon Paynter wrote:
ive tried WASession allInstances do: [ : item | item unregister].
and various other permutations.

Some sessions go away, but most do not.  So something else is hanging onto the sessions.  Eventually I will get fed up with my bloated image and reload everything from source.

If there is a reasonable way to track what is holding onto the sessions i can track that down and either fix my own bugs, or submit a new one here to the list.



On Wed, Feb 26, 2014 at 10:00 AM, Bob Arning <[hidden email]> wrote:
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:
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



_______________________________________________
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


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

Re: Session expiration and data cleaning

Jon Paynter-2
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:
You might try

PointerFinder on: WASession allInstances first

Cheers,
Bob

On 2/26/14 2:09 PM, Jon Paynter wrote:
ive tried WASession allInstances do: [ : item | item unregister].
and various other permutations.

Some sessions go away, but most do not.  So something else is hanging onto the sessions.  Eventually I will get fed up with my bloated image and reload everything from source.

If there is a reasonable way to track what is holding onto the sessions i can track that down and either fix my own bugs, or submit a new one here to the list.



On Wed, Feb 26, 2014 at 10:00 AM, Bob Arning <[hidden email]> wrote:
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:
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



_______________________________________________
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


_______________________________________________
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: Session expiration and data cleaning

Bob Arning-2
Ah, well. It's a squeak thing. Perhaps VW has something similar.

Cheers,
Bob

On 2/26/14 2:49 PM, Jon Paynter wrote:
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:
You might try

PointerFinder on: WASession allInstances first

Cheers,
Bob

On 2/26/14 2:09 PM, Jon Paynter wrote:
ive tried WASession allInstances do: [ : item | item unregister].
and various other permutations.

Some sessions go away, but most do not.  So something else is hanging onto the sessions.  Eventually I will get fed up with my bloated image and reload everything from source.

If there is a reasonable way to track what is holding onto the sessions i can track that down and either fix my own bugs, or submit a new one here to the list.



On Wed, Feb 26, 2014 at 10:00 AM, Bob Arning <[hidden email]> wrote:
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:
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



_______________________________________________
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


_______________________________________________
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


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

Re: Session expiration and data cleaning

Dave
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


Bob Arning-2 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].

Cheers,
Bob