about MADynamicObject and serialization.
It is used to put a calculated value into a variable. Whenever you send the first message to it, the block gets evaluated and the
This is the bit that I dont understand, I cant see where the 'evaluation' actually happens. Who does it? Where is the code that says 'aBlock value'?
What I find strange is that a MADynamicObject is ending up in the code to serialize.
Before persisting a PRContext, I was zapping its properties to nil. However I had omitted to do the same to the context's command's answer context, as in the case of a PRAddCommand. So it was in the dictionary of properties, containing references to components that was causing the problem. Exactly where WAProxyObject is in there I am not quite sure since I never got a proper debugger up on it. The PRCommandAdd-structureClasses appeared to be the one causing trouble, i.e. a reference to this dynamic object is contained in one of the components. ---- So now Pier-Magma is looking good to go. My main objective was to be able to have the Pier data persisted outside of the image so that an 'upgrade' of the image would be straightforward.
There are (at least) two more issues to consider if Magma-Pier is to be a tour-de-force.
1) At the moment pier-magma marks objects for rematerialisation as needed, one-by-one. Magma can be configured for different read-strategies, so performance could be greatly increased (so I am told) if the read strategy re-materialised on a page-by-page or kernel-by-kernel basis (for a multi kernel site).
2) Using a non-shared MagmaSession takes time to get the initial session on the database (it could hold a cached session ready in order to improve this), but when the session is expired the objects may be free to be purged from the image. (Thinking about it I suspect that this will not happen automatically with my current implementation, but it should)
My current preferred approach is to use a shared MagmaSession where there is only one MagmaSession for all the seaside sessions. Effectively this caches every used object in memory, and the opportunity for allowing objects to be purged/gc'd is less clear. I am assuming that Magma doesnt do an explicit purge, but relies upon the application to 'let go' of unneeded objects for gc to tidy up.
Keith
___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html
magma@lists.squeakfoundation.org