[Seaside] Garbage Collection/Handling

John Thornborrow john at pinesoft.co.uk
Fri Apr 13 12:12:54 UTC 2007


Philippe Marschall wrote:
> 2007/4/13, John Thornborrow <john at pinesoft.co.uk>:
>> Hi folks,
>>
>> I've recently noticed that despite having tight controls over the number
>> of instantiations requested for my objects within my application, there
>> is still a large number due to the session handling. This is perfectly
>> understandable, but I was wondering if there is a set process for
>> garbage collecting?
>>
>> So far I have been 'do'ing the below items just to clear things down
>> a bit..
>>
>> "kill seaside processes."
>> WAKom stop.
>> "make sure they're dead"
>> HttpService allInstances do: [:x | x stop].
>> "clears cached data"
>> WALRUCache allInstances do: [:x | x initialize].
>> "clears context data"
>> WARenderingContext allInstances do: [:x | x clearMode].
>> "expires sessions"
>> WASession allInstances do: [:x | x expire].
>> "default garbage collection - do this several times just to be sure"
>> Smalltalk garbageCollect
>>
>> Is there anything else I should consider?
>>
>> Also any pointers for use of control methods in my application would be
>> most welcome.. I'm using a registry for my #children methods, and in
>> callbacks where applicable (populated by lazy loaders) but I still find
>> areas such as child components which render callbacks have to use new
>> instantiations, which I'm not keen on. This could be resolved by passing
>> the registry further down the chain, but seems overkill just to avoid
>> overpopulating. Perhaps the #children method should return only
>> classnames and not objects instead?
>
> Squeak is object oriented so creating objects is not considered to be
> a problem.
>
> Philippe
>
>> Many thanks for any advice.
>> John.
>> www.pinesoft.co.uk
>>
>>
>> Pinesoft Computers are registered in England, Registered number:
>> 2914825. Registered office: 266-268 High Street, Waltham Cross,
>> Herts, EN8 7EA
>>
>>
>>
>> This message has been scanned for viruses by BlackSpider MailControl
>> - www.blackspider.com
>>
>> _______________________________________________
>> Seaside mailing list
>> Seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>
You seem to misunderstand :)

I'm not against instantiating objects, however I am against
instantiating many objects when only one object is needed.

An example..

Rootcomponent>>children
    ^Array with: SomeComponent new.

Rootcomponent>>renderContentOn: html
    html render: SomeComponent new.

Now, that is a *very* simple example - but it does demonstrate what I am
referring to - there are now two instances of SomeComponent, when only
one is needed. This will be resolved by a lazy loader, but for more
complex examples it is not easy.

My first thought is "Why does #children need to return an array of
objects, and not just an array of classnames so that it can #isKindOf:
the components as it renders?"

I am still learning with Seaside, but so far I can see that the
#children are then processed with #childrenDo: but I still ask "Why?"
Why must they have this processing here, and not at rendering?


More information about the Seaside mailing list