[Smallwiki] Re: MADynamicObject

[Keith Hodges]

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