Hi all,
I noticed that in recent versions of Seaside there was a change (to my knowledge) in the way Sessions and other objects in a WACache are reaped. I have a model where each Seaside session (my own subclass of WASession, GwSession) has a "system" object that has its own GlorpSession. So in the #unregistered I log out from the database, freeing the connection. So my question is: how is the cache reaping invoked? I noticed there is a #sweepIncrementally method that seems to be called before each access to the cache (this is new to me). Is there something else to it? Should I check somewhere else? For some reason, my unregister event is not freeing up the connections, even though the sessions expired both in absolute and relative age. I also need a pooled database accessor, but that's a different story :-). Regards! Esteban A. Maringolo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hi Esteban,
The cache implementation changed with Seaside 3.3 (https://github.com/SeasideSt/Seaside/wiki/Seaside330Changelog) As you say, the sweeping is done on every cache access. So, every time a session is accessed/created, the entire session cache is swept. (In Gemstone, this is different: a separate process is used to sweep the cache, where an instance of WABulkReapingCache is used instead). As far as I remember, this has not changed from previous 3.x versions. Does your session instance receive the #unregistered message ? Are relying on #expiredRegistryKey being sent to the app? Cheers Johan
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Hi Johan,
My session receives the #unregisted message now, I had another issue that was stopping me from receiving it (it was halting the session, so I never got it back). Regards! Esteban A. Maringolo On Wed, Aug 19, 2020 at 3:04 AM Johan Brichau <[hidden email]> wrote: > > Hi Esteban, > > The cache implementation changed with Seaside 3.3 (https://github.com/SeasideSt/Seaside/wiki/Seaside330Changelog) > > As you say, the sweeping is done on every cache access. > So, every time a session is accessed/created, the entire session cache is swept. (In Gemstone, this is different: a separate process is used to sweep the cache, where an instance of WABulkReapingCache is used instead). > As far as I remember, this has not changed from previous 3.x versions. > > Does your session instance receive the #unregistered message ? > Are relying on #expiredRegistryKey being sent to the app? > > Cheers > Johan > > On 17 Aug 2020, at 23:27, Esteban Maringolo <[hidden email]> wrote: > > Hi all, > > I noticed that in recent versions of Seaside there was a change (to my > knowledge) in the way Sessions and other objects in a WACache are > reaped. > > I have a model where each Seaside session (my own subclass of > WASession, GwSession) has a "system" object that has its own > GlorpSession. So in the #unregistered I log out from the database, > freeing the connection. > > So my question is: how is the cache reaping invoked? > I noticed there is a #sweepIncrementally method that seems to be > called before each access to the cache (this is new to me). Is there > something else to it? Should I check somewhere else? > > For some reason, my unregister event is not freeing up the > connections, even though the sessions expired both in absolute and > relative age. I also need a pooled database accessor, but that's a > different story :-). > > Regards! > > Esteban A. Maringolo > _______________________________________________ > 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 |
Free forum by Nabble | Edit this page |